COMponents mscomctl.ocx，mscomct2.ocx，mswinsck.ocx：以编程方式设置Kill-Bit

Question

在Windows 7上，标题中列出的COMponents默认情况下似乎将“killbit”设置为COMPAT_EVIL_DONT_LOAD（比较MSDN），即 Compatibility Flags in 默认情况下，HKLM \ SW \ IE \ ActiveX兼容性\ {＆lt; CLSID＆gt;} \ 似乎设置为该值：

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

当我将值设置为0时（这是Nirsoft's ActiveX Compatibility Manager在“激活”COMponent时所做的事情），一切正常。

[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 \ {＆LT; CLSID＆GT;} \ 的）。您是否知道一种方法，即批处理/（PowerShell）脚本/工具/用于查询与ocx文件或至少ProgID基础相关的CLSID的任何内容？
• 我了解CLSID在Windows 2000中是不变的，最多7？
• SlayOCX.vbs似乎是一种低级方法，可称为SlayOCX.vbs和here中描述的组策略，可以作为网络范围的解决方案。但是：它是一个vbs，在某些环境中关闭。此外，我将最终得到一个要由此脚本检查的CLSID列表。包裹，例如在批处理中，我可能无法以所描述的方式由客户的管理员部署它，而是通过注册表中的登录脚本或runonce键或其他东西 - 不是很优雅。那么你会建议什么？我更喜欢一个解决方案（一个工具，一个我还不知道的新组策略，一个更复杂的脚本，对系统和安全配置问题的依赖性更小......），这使得第一个信息问题变得多余。 / LI>

Answer 1

您是否想要故意让客户暴露于安全漏洞？我不是律师，但是......

根据this post，提到的文件是“支持您的应用程序分发的运行时文件”，您只需要更新到最新版本。

另一篇文章详细介绍了必要的步骤（可能是针对较旧的更新，但仍然应该让您入门）：Clickety

Answer 2

CLSID Registry Scanner (COM/ActiveX)

是我对自己问题的回答。它现在正在工作，这对我来说很重要。如果重写或至少翻新程序，或者两者都独立，并摆脱旧帽子，那将是一个没有实际意义的讨论。因为我不做出预算决定，所以没有实际意义。

Answer 3

除了Treeview替换代码或API调用可以找到这些OCX的大多数用法。显然，几年前有一些德国评论的API代码可供树视图购买。无论如何，所有这些OCX都是API调用的包装器。

请参阅我网站上的Calendar Tips page

mswinsck有点棘手，我没有这个的URL。但是我确信可以找到可以在VBA中运行良好的VB6代码。

博客发布 - An older version of MSCOMM32.OCX has had the "kill bit" flag set.虽然你没有提到这个。