组件 mscomctl.ocx、mscomct2.ocx、mswinsck.ocx：以编程方式设置 Kill-Bit

发布于 2024-10-15 23:22:00 字数 1947 浏览 7 评论 0原文

在 Windows 7 上，标题中列出的组件默认情况下似乎将“killbit”设置为 COMPAT_EVIL_DONT_LOAD（比较 MSDN），也就是说，它们在 HKLM\SW\IE\ActiveX Compatibility\{}\中的兼容性标志似乎默认情况下设置为该值：

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

当我将该值设置为 0 时（这就是 Nirsoft 的 ActiveX 兼容性管理器在“激活”组件时执行），一切正常。

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

但这只是一个工作站的 GUI 解决方案。为了部署我们的软件，我需要一个安全稳定的程序（脚本或工具）来附带我们的软件，它不仅将“killbit”设置为 0 或删除注册表项（应该首选哪个程序？），而且检查如果没有必要的话，什么都不做。优选地，解决方案将仅传递文件名或文件列表，并自行处理其他必要的事情。

这就是更大的问题开始的地方：

关于 COM 对象，注册表是通过 CLSID 查询的，而不是通过 ocx 文件名（即 Windows 注册表中的 InProcServer32 条目）或 ( VersionIndependent)ProgID (HKLM\Software\Classes\CLSID\{}\)。您是否知道一种方法，即批处理/（PowerShell）脚本/工具/任何查询与 ocx 文件或至少 ProgID 根相关的 CLSID 的方法？
我了解 Windows 2000 中的 CLSID 最多为 7？
SlayOCX.vbs 似乎是一种低级方法，称为组策略，如 SlayOCX.vbs 和此处，可以作为网络范围的解决方案。但是：它是一个vbs，在某些环境下关闭。此外，我最终会得到一个由该脚本检查的 CLSID 列表。例如，打包成一批，我可能无法让客户管理员以所描述的方式部署它，而是通过登录脚本或注册表中的 runonce 密钥或其他方式进行部署 - 不是很优雅。那么你有什么建议呢？我更喜欢一个解决方案（一个工具，7 中的一个新组策略，我还不知道，一个更复杂的脚本，对系统和安全配置问题的依赖性较小，...），这使得第一个信息问题变得多余。

原文

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.