views:

370

answers:

1

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:

  1. 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.
  2. The same VBScript works correctly on a 32-bit Windows XP machine and a 32-bit Windows Server 2003 machine.
  3. 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:

  1. Is there a core problem that is always behind a "catastrophic failure" from a Windows scripting host calling a COM component?
  2. 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"?
  3. 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.

+1  A: 

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.

Hans Passant