Geek Answers Handbook

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

I need a mind reading because I'm trying to do what I don't understand.

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

Now I have a 64-bit Windows Vista Home that makes my head spin. Excel examples work very well (in Excel 2003). Compiled .NET sample executables also work.

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

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

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

PS: I believe that the code examples here do not make much sense, but this is a VBScript line that 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 work with an account with administrator rights.

I also tried to see which registry keys are read using Process Monitor, but everything looks fine for the GUID of this object. I could not recognize the other GUIDs, so I'm not sure if they were critical or not.

Is it likely that this COM object is using Internet Explorer and receiving the wrong one (for example, Internet Explorer 7 instead of the Internet Explorer 6 engine or something like that)?

+4
source share
3 answers

There are several things you should remember with a 64-bit machine. These are some of the things that have caught me in the past.

  • Creating any processor in .NET means it will work like 64 bits on a 64-bit machine.
  • A lot of COM components seem only 32-bit (I know this is a generalization, but often the case). To use them, you need to create an application as 32 bits (x86).
  • The 64-bit version of 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 was to create a 32-bit application and see what happens.

+3
source

The problem is probably in DEP.

I had the same problem as yours and got some help from CQG technical support. Data Execution Prevention is turned on by Windows Vista and Windows 7 by default. You can disable it on the command line with administrator privileges using

 bcdedit.exe /set {current} nx AlwaysOff

Later, if you need to, you can enable it with

 bcdedit.exe /set {current} nx AlwaysOn

A reboot is not requested, but 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 replacing mine with Always Off and rebooting, I was able to compile without throwing error 80004005.

+1
source

Some useful things you could try:

  • Start the process monitor with the output filtered during the failure. Check to see if any odd errors are being reported.

  • Similarly, try running under an unmanaged debugger and see if any other exceptions are thrown for the first case. This will also allow you to confirm whether the inproc COM COM library is loading.

  • Try turning off UAC and see what happens.

0
source

More articles:


All Articles