XPost: alt.windows7.general

Hello all,

A few days ago I decided to check the CLSID entries in my registry (I've
been installing and un-unstalling ActiveX components). I found some which pointed to programs/dlls which do not exist :

BdaPlgin.ax
CaPlgin.ax
deskpan.dll
eapahost.dll
eapa3hst.dll
mscoree.dll

a few of those exist in multiple CLSIDs, and all of them are under the "InProcSever32" subkey. I googled for few and found that they are some
kind of remainder ... of something related to the OS.

What I would like to know if I can just delete those CLSID entries, or if
they stil are needed. If it makes any difference, the involved OS is
XPsp3.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general

"R.Wieser" <address@not.available> wrote

| A few days ago I decided to check the CLSID entries in my registry (I've
| been installing and un-unstalling ActiveX components). I found some
which
| pointed to programs/dlls which do not exist :
|
| BdaPlgin.ax
| CaPlgin.ax
| deskpan.dll
| eapahost.dll
| eapa3hst.dll
| mscoree.dll
|
| a few of those exist in multiple CLSIDs, and all of them are under the
| "InProcSever32" subkey. I googled for few and found that they are some
| kind of remainder ... of something related to the OS.
|
| What I would like to know if I can just delete those CLSID entries, or if
| they stil are needed. If it makes any difference, the involved OS is
| XPsp3.
|

I checked for eapahost and found I also have settings but
no file. Mscoree is the .Net interpreter. You'll need that
if you have any .Net. I'm not sure how that works. .Net breaks
COM, but somehow it's using the same system for its own
object model.

With anything else, those entries are there to enable COM dispatch
library loading, as you probably know. The ProgIDs and CLSIDs
allow software to find a COM object and load it, without needing
to know the file or its location.

If the file is not there, or if you delete the CLSID, you'll probably
get the same error if you try to instantiate that object:
Error 429. Unable to create ActiveX object.

But as long as nothing is trying to use the library it won't matter.
In other words, if AcmeSoft installs abc.dll and registers COM
objects, that's only relevant as long as the DLL remains on your
system, remains registered, and is used by some kind of software,
such as AcmeSoft editor. If nothing ever tries to use the COM
object(s) then it won't matter. If something tries to use them and
the library is not there, you'll get an error. You're only breaking
something if the file is there, properly registered, and some software
is using it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.windows7.general

Mayayana,

You're only breaking something if the file is there, properly
registered, and some software is using it.

The thing is that with these pre-created CLSID entries the involved
component could just be dropped in place. Removing those CLSID entries
could than cause the program trying to reach them to fail.

Yes, I know that not calling the components "DllRegisterServer" function
would be an odd thing to do, but I'm not directly willing to bet it won't
ever happen that way.

And thats pretty-much what I'm trying to verify : that noone has ever experienced something like that (and I thus can just remove those CLSID entries).

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"R.Wieser" wrote:

The thing is that with these pre-created CLSID entries the involved
component could just be dropped in place. Removing those CLSID entries
could than cause the program trying to reach them to fail.

Which might be a good thing. deskpan.dll (control panel extension) and
the EAPHost Authenticator Service (don't know which particular file[s])
have been associated with exploits (see MS11-071 security bulletin).

And thats pretty-much what I'm trying to verify : that noone has ever experienced something like that (and I thus can just remove those CLSID entries).

I have two installations of XPsp3 (32 bit); one "Professional" with
minimal updates and the other "Home" pretending to be a point of sale
device fully updated until a couple of years ago.

The pro version has registry entries for all but the files are not
installed. BdaPlgin.ax is in both service packs but not in any Windows directory. The dot-net runtime engine (mscoree.dll) is also only in
a service pack directory but the NET framework is not present on this
machine. However, the MS management Console (mmc.exe) has components
(an additional exe and DLLs) that depend on mscoree. I've not had
problems with running mmc or the .msc files it uses.

The fully updated POS machine (a laptop) does have the NET framework
and mscoree.dll has many registry entries, the file itself being in
system32. However, none of the other files have any trace in the
registry and none are installed in any Windows directory. I've done
similar reg cleaning exercises so I don't know if it's a result of
that or subsequent updates. All are MS files but I've had no problems
with their absence.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Apd,

Which might be a good thing. deskpan.dll (control panel extension) and the EAPHost Authenticator Service (don't know which particular file[s]) have
been associated with exploits (see MS11-071 security bulletin).

Yep, I've read similar. But no, a legit program not being able to reach
its legit components would /not/ be a good thing. :-)

The whole exploit seems to b caused by 1) the CLSID entries being there 2)
the components not having full, absolute pathnames 3) the way Windows
searches for a filename that does not contain a path.

In other words : afaics the same trick can be used for /any/ components
which is referred to using only its filename (no path) - regardless of if it already exists or not.

All are MS files but I've had no problems with their absence.

I've got two 'puters set up similary to yours : one which has had minimal updates, and another which has a few, including .net . Both have been
working fine for a number of years. Thats not the problem.

My problem is that I simply do not know if removing those non-functional
CLSIDs will break anything. Now, or in the future. I don't /think/ so,
but ...

I just thought that /maybe/ someone else here might have checked the same
and had some experience with it. Than again, I don't think that what I've
been doing is common, so chances to it are slim-to-none. :-\
Nonwithstanding, I had to ask.

I'll probably just rename the involved CLSID GUIDs (so I can change them
back) and see what happens ...

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 1 Dec 2021 16:53:56 +0100, R.Wieser wrote:

Hello all,

A few days ago I decided to check the CLSID entries in my registry (I've
been installing and un-unstalling ActiveX components). I found some which pointed to programs/dlls which do not exist :

BdaPlgin.ax
CaPlgin.ax
deskpan.dll
eapahost.dll
eapa3hst.dll
mscoree.dll

a few of those exist in multiple CLSIDs, and all of them are under the "InProcSever32" subkey. I googled for few and found that they are some
kind of remainder ... of something related to the OS.

What I would like to know if I can just delete those CLSID entries, or if they stil are needed. If it makes any difference, the involved OS is
XPsp3.

Regards,
Rudy Wieser

They are preinstalled registry data for optional features or optional
hardware. And IMO, as well as remnants of dropped features which Microsof didn't mention or be mentioned anywhere else.

It's like how Windows XP preinstall ATI and S3 display drivers whether the system actually has one of those hardwares or not. One may say that they are required. It's not. Windows should only preinstall the standard VGA driver. This also applies to Ensoniq audio related DLLs, where Windows should only preinstall the standard AC-97 audio related files instead of preinstalling manufacturer-specific files which may not be used at all.

That DESKPAN.DLL is presumably part of a dropped Windows 2000 or NT5.x
feature. That file is not included in any of Windows 2000, Windows 2000
Server, Windows XP, and Windows 2003 (Server) CD-ROMs. Vista or NT6+ no
longer has any reference to it in the registry. Windows NT4 and all older versions do not have any reference to it yet. And AFAIK, Windows has no
built in feature to have a desktop workspace which is larger than the screen
in a single monitor, and be able to pan it. Not even Windows 8 and 10.

Whether it's safe to delete the irrelevant registry data and/or files, would depend on what they are for, whether they actually exist in the system or
not, and if they exist, whether you actually use them or not.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

Whether it's safe to delete the irrelevant registry data and/or
files, would depend on what they are for, whether they actually
exist in the system

Well, thats what I started with : those files definitily do not exist on my 'puter.

The whole question is if I could possibly muck something up by removing the related registry keys.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2 Dec 2021 15:07:38 +0100, R.Wieser wrote:

JJ,

Whether it's safe to delete the irrelevant registry data and/or
files, would depend on what they are for, whether they actually
exist in the system

Well, thats what I started with : those files definitily do not exist on my 'puter.

The whole question is if I could possibly muck something up by removing the related registry keys.

Regards,
Rudy Wieser

There is a possibility that removing one can break something. Considering
that Windows has Application Compatibility feature which is a built in application patching feature. It can be used to patch application/library to use/receive different registry data, use other file, or make the kernel
behave differently.

IMO, the best way to find out is to use Microsoft Process Monitor (older version if Windows XP) to monitor registry and file operations.
Additionally, searching the GUID (both as string as well as binary) in all
of system files would help.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)