Using 32-bit COM object from C# or VBS on Vista 64-bit and getting error 80004005

Question

I need some mind reading here, since I am trying to do what I do not completely understand.

There is a 32-bit application (electronic trading application called CQG) which provides a COM API for external access. I have sample programs and scripts which access this API from Excel, .NET (C++, VB and C#) and shell VBScript. I have these .NET applications as source code and as compiled executables (32-bit, compiled on Windows XP).

Now I have Windows Vista Home 64-bit which makes my head to spin. Excel examples work just fine (in Excel 2003). Compiled .NET sample executables work as well.

But when I am trying to run .NET C# sample converted to and compiled by Visual Studio C# Expression, or run the VBScript script, I am getting error 80004005 when trying to create an object. Initially the .NET application also gave me 80040154 but then I figured how to make it produce 32-bit code and not 64-bit, so now the errors in C# and VBScript applications are the same. That's all the progress I got for now.

And yes, I tried running 32-bit versions of cscript.exe/WScript from SysWOW64 folder on my VBS, but still the result is the same (80004005).

How to solve this problem? I am almost ready to believe it is practically impossible, but the fact that Excel VBA works and .NET executables compiled on Windows XP run just fine just makes me angry. There should be a way to beat this thing (some secret which probably only Windows Vista developers know)! I will appreciate any help!

PS: I believe code samples do not make much sense here, but this is the line of VBScript which fails:

Set CEL = WScript.CreateObject("CQG.CQGCEL.4.0", "CEL_")

And this is C#:

CQGCEL CEL = new CQGCEL();

Update: Forgot to say UAC is off, of course. And I am working from account with administrator priviledges.

I also tried watching which registry keys are read using Process Monitor but everything looks OK for GUIDs of this object. I could not recognize some other GUIDs so I am not sure whether they were critical or not.

Is there a chance that this COM object uses Internet Explorer and gets the wrong one (like Internet Explorer 7 instead of Internet Explorer 6 engine or something)?

Answer 1

A couple of useful things you could try:

1. Run process monitor with the output filtered to the failing process. See if any odd errors are reported.

2. Similarly, try running under an unmanaged debugger and seeing if any other first chance exceptions are thrown. This will also let you confirm if the inproc COM dll is being loaded into the process.

3. Try turning UAC off and seeing what happens.

Answer 2

There are a number of things you have to remember with a 64 bit machine. These are some things that have caught me out in the past.

1. Building for Any CPU in .NET means it will run as 64 bit on a 64 bit machine.
2. Lots of COM components seem to be 32 bit only (I know this is a generalisation, but is often the case). In order to use them, you need to build your application as 32 bit (x86).
3. 64 bit Windows has different 32 and 64 bit registry nodes. For example, if you run regedit as 64 bit, you will see HKLM\Software\Wow6432Node and HKCU\Software\Wow6432Node. This contains all the information for 32 bit applications.

My suggestion would be to build as a 32 bit application and see what happens.

Answer 3

The problem is probably DEP.

I had the exact same problem as you, and got some help from tech support at CQG. Data Execution Prevention is turned on by Windows Vista & Windows 7 by default. You can turn it off with in command prompt with admin rights using

bcdedit.exe /set {current} nx AlwaysOff

Later, if you need, you can turn it back on with

bcdedit.exe /set {current} nx AlwaysOn

Reboot is not prompted, but is necessary. You can check your DEP policy using

wmic OS Get DataExecutionPrevention_SupportPolicy

where 0 is Always off, 1 is Always On, 2 is Opt in (and the default value), and 3 is Opt Out.

After changing mine to Always Off and rebooting, I was able to compile without throwing the 80004005 error.