如何解决“灾难性故障”在 SysWOW64\cscript 或 wscript 中使用 32 位 COM 组件
我正在尝试运行一个使用 7 年历史的第三方 32 位 COM 组件的 VBScript 脚本 在 Windows Server 2008 R2 上，使用命令行 32 位脚本主机 SysWOW64\cscript.exe。当我在类上调用 CreateObject 时，它似乎是成功的，但是当我第一次尝试在对象上使用属性或方法（我已经尝试了几种不同的）时，它给了我“灾难性的失败”。我使用 SysWOW64\wscript.exe 得到了相同的结果，当然，除了我的错误消息出现在 msgbox 中而不是命令行窗口中。
我认为这与 64 位脚本主机特别相关，因为以下原因：
- 等效的经典 ASP 脚本调用相同的组件并使用 95% 的相同代码，在同一台服务器上正常工作，并将 IIS 配置为支持32位COM。
- 相同的 VBScript 在 32 位 Windows XP 计算机和 32 位 Windows Server 2003 计算机上可以正常工作。
- 该组件在我的 64 位 Windows 7 计算机上以完全相同的方式失败。
我在 Google 上搜索此问题的解决方案，大部分都发现了许多不同的问题，这些问题都是通过将 COM 组件放入 Visual Studio 中的工具栏来解决的。显然，该解决方案不适用于此处。
我的问题是：
- Windows 脚本主机调用 COM 组件的“灾难性故障”背后是否始终存在核心问题？
- 配置管理单元或注册表中是否有一个位置需要进行类似于我必须对 IIS 应用程序池进行的更改以“启用 32 位应用程序”？
- Server 2008 R2 事件查看器中是否有一个我应该查看的一般位置，以查看是否有有关故障的更多详细信息，以防它特定于该组件？
提前致谢。
I'm trying to run a VBScript script that uses a 7-year-old 3rd-party 32-bit COM component
on Windows Server 2008 R2, with the command-line 32-bit script host, SysWOW64\cscript.exe. When I call CreateObject on the class, it appears to be successful, but the very first time I try to use a property or method (I've tried several different ones) on the object, it gives me the "catastrophic failure". I have identical results with SysWOW64\wscript.exe, except, of course, that my error message comes in a msgbox instead of the command-line window.
I think this has to do specifically with the 64-bit scripting hosts because of the following:
- The equivalent Classic ASP script, calling the same component and using 95% of the same code, works correctly on the same server, with IIS configured to support 32-bit COM.
- The same VBScript works correctly on a 32-bit Windows XP machine and a 32-bit Windows Server 2003 machine.
- The component fails in exactly the same way on my 64-bit Windows 7 machine.
My Google searches for solutions to this problem have mostly turned up a lot of different problems that were solved by putting the COM component into a toolbar in Visual Studio. Obviously, that solution doesn't apply here.
My questions are:
- Is there a core problem that is always behind a "catastrophic failure" from a Windows scripting host calling a COM component?
- Is there a place in a configuration snap-in, or in the registry, where I need to make a change similar to the change I had to make to the IIS Application pool to "Enable 32-bit Applications"?
- Is there a general place in the Server 2008 R2 Event Viewer that I should be looking, to see if there are any more details on the failure, in case it turns out to be specific to this component?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不要阅读错误文本中的任何内容。 “灾难性故障”肯定是有史以来最糟糕的 HRESULT 代码。程序员使用了E_UNEXPECTED错误代码，这在COM编程中很常见。它通常表示“我无法完成这项工作，但我不知道为什么”。当然，这并没有给你留下很多选择来找出原因。
它不太可能与在 64 位版本的 Windows 上运行直接相关。您正在使用 32 位脚本主机，它们在为 COM 服务器提供 32 位执行环境方面做得非常出色。更有可能的是，安装过程中出现了一些问题，缺少某种组件。弄清楚这一问题的唯一好方法是联系 COM 服务器的作者或供应商以获得支持。如果这不切实际，请考虑在启动早期版本 Windows 的虚拟 PC 中运行它。
Don't read anything in the error text. "Catastrophic failure" must be the worst named HRESULT code ever. The programmer used the E_UNEXPECTED error code, it is common in COM programming. It usually indicates "I can't make this work, but I don't know why". Which of course doesn't leave you with many options to figure out why.
It is unlikely that it is directly related to running on a 64-bit version of Windows. You are using the 32-bit scripting hosts, they do an excellent job of providing a 32-bit execution environment for COM servers. Much more likely is that there simply is something amiss with the install, some kind of missing component. The only good way to get to the bottom of this is by contacting the author or vendor of the COM server for support. If that's impractical, consider running this inside a virtual PC that boots an earlier version of Windows.