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

"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.

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

"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.

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

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.

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

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.