1. Forum
  2. Usenet
  3. MICROSOFT.PUBLIC.WINDOWSX

  • Some CLSID references found to non-existing programs. Can the CLSIDs be

    From R.Wieser@21:1/5 to All on Wed Dec 1 16:53:56 2021
    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)
  • From Mayayana@21:1/5 to R.Wieser on Wed Dec 1 12:13:55 2021
    XPost: alt.windows7.general

    "R.Wieser" <[email protected]ble> 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)
  • From R.Wieser@21:1/5 to All on Wed Dec 1 21:08:44 2021
    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)
  • From Apd@21:1/5 to R.Wieser on Thu Dec 2 00:58:26 2021
    "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)
  • From R.Wieser@21:1/5 to All on Thu Dec 2 09:27:14 2021
    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)
  • From JJ@21:1/5 to R.Wieser on Thu Dec 2 16:52:31 2021
    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)
  • From R.Wieser@21:1/5 to All on Thu Dec 2 15:07:38 2021
    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)
  • From JJ@21:1/5 to R.Wieser on Fri Dec 3 15:23:30 2021
    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)