Search code examples
ms-accessvbaregistryactivexobject

COMponents mscomctl.ocx, mscomct2.ocx, mswinsck.ocx: set off Kill-Bit programmatically

On Windows 7, the COMponents listed in the title seem by default to have the "killbit" set to COMPAT_EVIL_DONT_LOAD (compare MSDN), that is, their Compatibility Flags in HKLM\SW\IE\ActiveX Compatibility\{<CLSID>}\ seem to be set to that value by default:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{B09DE715-87C1-11D1-8BE3-0000F8754DA1}]
"Compatibility Flags"=dword:00000400

When I set the value to 0 (that's what Nirsoft's ActiveX Compatibility Manager does when "activating" a COMponent), everything works fine.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{B09DE715-87C1-11D1-8BE3-0000F8754DA1}]
"Compatibility Flags"=dword:00000000

But this is just a GUI solution for one workstation. To deploy our software, I need a safe and stable procedure (script or tool) to ship with our software, that not only sets the "killbit" to 0 or deletes the registry entry (which procedure should be preferred?), but checks the situation before and does nothing if nothing is necessary. Preferably, the solution would just be passed over a file name or a list of files and proceeds everything else necessary on its own.

This is the point where the bigger questions begin:

  • Regarding COM objects, the registry is queried by CLSID, not by ocx file name (that is the InProcServer32 entry in the Windows registry) nor by (VersionIndependent)ProgID (HKLM\Software\Classes\CLSID\{<CLSID>}\). Do you know a method, i.e., a batch / (PowerShell) script / tool / whatever to query the CLSIDs related to an ocx file or at least the ProgID radical?
  • I understand the CLSID is constant in Windows 2000 up to 7?
  • SlayOCX.vbs seems to be a low level approach that, called as a group policy as described in SlayOCX.vbs and here, could work as a network-wide solution. But: It's a vbs, switched off in some environments. Furthermore, I will end up with quite a list of CLSIDs to be checked by this script. Wrapped e.g. in a batch I will probably not be able to have it deployed by the customers' admins in the described way, but rather by logon script or runonce key in the registry or something -- not very elegant. So what would you suggest? I'd prefer a solution (a tool, a new group policy in 7 I don't know yet, a more sophisticated script with less dependency on system and security configuration issues, ...) that makes the first informational questions superfluous.
Solution

  • CLSID Registry Scanner (COM/ActiveX)

    is my answer to my own question. It's working for now, that's important for me now. It would be a moot discussion if it was not better to rewrite or at least refurbish the program, or both independently, and get rid of old hats. Would be moot because I do not make our budget decisions.