VS2008 Interop issue

Question

I have an old COM object that I have been using with C#.  Prior to VS2008 this worked fine on Vista, XP, W2k3 (all 32 bit) using VS2005.  After converting the app to VS2008 I now get: "System.BadImageFormatException: Retrieving the COM class factory for the component with CLSID {...} failed due to the following error: 800703e6" whenever I try to instantiate the object.  However in VS2008 this still works fine on W2k3 and XP.  Any suggestions?

 

I have also tried:

1. to "wrapper" the object in a .NET dll created and complied in VS2005 and call it.. same problem
2. copying a working version from XP or W3k3 to my Vista box, same problem
3. recreate the app from scratch in the 2.0, 3.0 and 3.5 frameworks on Vista, same problem

thanks

Answer 1

Error 80070386 means invalid access to a memory location.  Recreating the app in 2008 for .NET 2.0 should be the same as creating the app in 2005.  Sounds like there's something wrong with the COM component.

 

Answer 2

Why would the COM component have a problem though since it works in all environments except Vista and VS2008?  I think the problem is happening at runtime and the way that VS2008 on Vista handles it has changed from the way VS2005 handles it.  Is there anyone that can describe the differences for the way they each handle runtime?

 

Answer 3

You've verified it works with Vista and VS2005?  A VS2008 .NET 2.0 project would produce the same assembly as VS2005...

Answer 4

Yes.  Here are all the combinations I have tried:

XP, VS2005 = works

XP, VS2008 = works (using 2.0, 3.0, 3.5)

W2k3, VS2005 = works

W2k3, VS2008 = works  (using 2.0, 3.0, 3.5)

Vista, VS2005 = works

Vista, VS2008 = does not work.  (regardless if I am using 2.0, 3.0, 3.5)

 

I even tried taking executables that worked from both XP and W2K3 that were created in VS2008 copied them to Vista and still no go.  But I could take the same code from those two boxes that was compiled in VS2005 and that worked fine as well.

 

What is really interesting that even though it won't run on Vista, it will still compile.  And if I then take that compiled code from Vista and run it on XP it runs fine... so this would lead me tp believe it is a runtime error as Premiere-30 suggested.

 

Answer 5

Vista,VS2005 and Vista,VS2008 .NET 2.0 both use the same compiler and runtime.  I'd be very surprised if it anything to do with the runtime.  I'd suggest logging it at http://connect.microsoft.com/visualstudio or contacting customer support, if it's important.

 

Answer 6

I agree... I can't see why it would be different either... but obviously it is.

 

I went ahead and posted the bug in connect. I will also forward the info to my TAM.

 

thanks!

 

Answer 7

I recently encountered a similar issue with Vista and VS2008.  I haven't been through all the same troubleshooting steps with testing VS2005, but this was not an issue before I upgraded to VS2008.  Have you been offered or have you found a solution to this issue yet?

 

Answer 8

 

Starting with .NET 2.0 SP1, which is a part of .NET 3.5, we’re now NX compliant for managed code.  So, any image you compile with VS2008, or VS2005 with .NET 2.0 SP1, will include IMAGE_DLLCHARACTERISTICS_NX_COMPAT in the PE headers.  This tells DEP that we support it.  This means that the image will be subject to DEP policy, so we shouldn’t be executing any code that is in a section of memory that is not marked as executable.  This is a security measure to try to prevent malicious code being injected.

 

The real fix is for the SAClient80MP.dll to be recompiled so that it is NX compliant.  The workaround is to disable DEP, or to use editbin.exe to remove the PE header for NXCOMPAT.  Editbin.exe is part of the .NET 2.0 SDK.

 

Here’s some information about DEP.

http://msdn2.microsoft.com/en-us/library/aa366553.aspx

Answer 9

 

This is very recently documented on this blog: http://blogs.msdn.com/ed_maurer/archive/2007/12/14/nxcompat-and-the-c-compiler.aspx

 

I am wondering if this change would have any impact to ASP.NET or the aspnet_wp.exe process is not run with DEP on, so it doesn't matter if the ASP.NET assemblies or the components they use are NX-compatible or not?!

 

Anyone experiencing a crash with their ASP.NET apps after upgrading to .NET 2.0 SP1 (or .NET 3.0 SP1; or .NET 3.5) on a machine with DEP on?

 

Cheers,

 

Kima

Answer 10

 

This has been some good information.  Unfortunately, I can't get around the issue.  I tried to turn off DEP on Vista, and then my computer would BSOD on bootup.  The BSOD went by so quickly I could never read what was displayed.  Setting it back to OptIn allowed me to boot again.

 

I've used 'editbin' to remove the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag from all DLL's and the EXE for my project, and I still get the 800703e6 error when trying to load the DLL.  I'm using code similar to the following:

 

Code Block

Type t = Type.GetTypeFromCLSID(new System.Guid("{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"));

object comObj = Activator.CreateInstance(t);

 

 

When I execute the 2nd line, the System.BadImageFormatException is thrown.  I find it very interesting that Premiere-30 mentions 'SAClient80MP.dll' in the one post.  While this is not the DLL I'm having problems with, it's an earlier version from the same vendor (Mercury Interactive now bought by HP).  I seriously doubt HP will step back and recompile their older release DLL's to fix this DEP issue, and I really need to find a solution that doesn't rely on them.

 

Is there something I'm missing on the 'editbin' technique?  Anything else I can try?  I even tried running it on all the vendor DLL's, but that didn't work for me either.

Answer 11

 

Has anybody been able to solve this when getting the same error from unit tests in VS2008? On the testable dll's I have used this editbin.exe and the dll's work with executables without any issues, it's just that on unit test project these do not work.

 

These used to work perfectly during VS2005...

 

Any thoughts on this?

Answer 12

Yes, recompile the problem dlls with the .Net framework 2.0 SP1 or greater then you won't have to mess with editbin.

Answer 13

 

Would be the perfect option, but as I have only the binaries, can not really do that. These .dll's are only used as part of our application and right now there is no way to access these to do unit testing on VS2008... bad...bad...

 

//Ilpo

Answer 14

Forgive me if this is a dumb suggestion given all the talk about DEP, but are you running VS2008 on Vista as Admin?

Answer 15

 

Yes, not a permission issue...

 

Might add to this that same error is coming up when debugging under the option of 'Enable the Visual Studio hosting process', now on unit testing world I don't see how to get rid of this option!

 

--------------
http://onroad.juvander.fi/community/blogs/ilpo

Answer 16

Was there ever a solution to this problem?  I am trying to instaniate a new connection to the Quality Center API (TDConnection) and I am getting this error with Windows Vista and Visual Studio 2008.



+  $exception {"Retrieving the COM class factory for component with CLSID {C5CBD7B2-490C-45F5-8C40-B8C3D108E6D7} failed due to the following error: 800703e6."} System.Exception {System.BadImageFormatException}

thanks

Answer 17

Just a note on the BSOD, In your BIOS you can change it so it does not reboot on Critical Errors.

Answer 18

I have the same error. Do you have a solution.
[e-mail]

Answer 19

Solved for me!

I'm using the Quality Center API version 9.2 and started to get this error when I run my C# assembly outside Visual Studio (it does not happen when running it in debug mode in Visual Studio). I'm using Vista SP1, VS 2005 and VS 2008.

The exact Error I got was:
Retrieving the COM class factory for component with CLSID {C5CBD7B2-490C-45F5-8C40-B8C3D108E6D7} failed due to the following error: 800703e6.

After running
editbin.exe /NXCOMPAT:NO <your binary>
It all went away. Details to be found here: NXCOMPAT and the C# compiler . No need for any changes to the Vista configuration, only your assembly. I used the Task Manager to verify that my assembly no longer had DEP enabled.

Answer 20

Compiler issue with VS2005 vs. VS2008 (C# 2.0 vs. C# 3.5) only on
  Vista with interop
 
  Hi there
 
  We found some issue we cannot explain and further more cannot fix.
 
  We build a C# library talking to a 3rd party server application which
  is offering an unmanaged API. We make massive use of COM Interop and
  for a long time everything worked fine. Since this application is
  32bit, the library and the application calling the lib is compiled
  with the x86 and not the AnyCPU Plattform flag
 
 After switching from Visual Studio 2005 to 2008 (and the v3.5-compiler)
 the application refuses to work on Vista64. It works on some
 Vista32 machines, on others it doesn't. Using the compiler (csc.exe)
 directly without Visual Studio leads to the same result.
 Going back and use binaries compiled with csc2.0 make it work again.


  I will collect a list of scenarios and the results:
 
  Compiling the lib using csc.exe 2.0 / running on XP or Vista - Working
 
  Compiling the lib using csc.exe 3.5 / running on XP - Working
 
  Compiling the lib using csc.exe 3.5 / running on Vista 32 - Working
  on some machines
 
  Compiling the lib using csc.exe 3.5 / running on Vista 64 - NOT Working
 
  
 
  But:
 
  Running Visual Studio 2008 on Vista 64 and debugging the lib inside
  VS 2008 - Working.
 
  The same but disabling the VS host process - NOT Working
 
  Using the same assembly but starting the exe - NOT Working on Vista
  64 (on the same machine)
  
  There must be some difference within the compilers. We tried to
  compile on different OS without any difference.
 
  On Vista we checked again with Administrator rights an UAC turned
  off. This posting seems to be something similar but turning DEP off
  on our test system doesn’t make any difference
 
  Can someone provide us with information about the difference of the
  C# compilers? Is there some hidden option and what’s going on on Vista?

Answer 21

I'm having the same problem in Vista 32-bit with VS 2008.  I tried adding the following to my post-build but I still get the COM error:

call "$(DevEnvDir)..\Tools\vsvars32.bat"
editbin.exe /NXCOMPAT:NO "$(TargetPath)"