Alternate cause of BadImageFormatException in .NET Assembly?

▲
6
▼

I'm working on a .NET 3.5 console application in C# which uses a VC++ unmanaged DLL. It ran without a problem when I worked on it a few weeks ago, but I'm coming back to it today and am now getting a BadImageFormatException ("An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)).

My development workstation is running 64bit Windows 7, and I do a fair amount of work with unmanaged code, so I immediately checked that the .NET assembly and the VC++ library both had x86 targets. They did.

Just to be sure, I cleaned and rebuilt the VC++ library and the .NET assembly, to no avail.

Neither system is doing anything particularly unusual. The VC++ library loads a binary data file and does some mathematical processing on its contents. The .NET assembly has the DllImports for the library and some code to wire it up. This all worked a few weeks ago.

So now I'm left wondering if there's some other cause of BadImageFormatException that's less common than an x86/x64 conflict that I might be running into.

Thanks.

EDIT: I get the same error regardless of x86 or x64 mode, but when set to 'Any CPU', execution gets past that point, but execution aborts on a later call to the VC++ library with no exception. Regardless of whether that is related to this problem, is there something that 'Any CPU' does differently from both x86 and x64 which could shed some light on this?

c#
c++
visual-studio
visual-studio-2008
dllimport
asked on Stack Overflow Mar 22, 2010 by Phillip Knauss • edited Mar 22, 2010 by Phillip Knauss

5 Answers

▲
4
▼

When I get this error it is always caused by loading a 32 bit DLL in a 64 bit process.

Set the EXE file to compile to x86 and see if it works.

answered on Stack Overflow Mar 22, 2010 by Arve
▲
3
▼

You may be trying to load an assembly built for CLR 4.0 on CLR 2.0.

answered on Stack Overflow Mar 22, 2010 by mmx
▲
3
▼

Check for a .dll load conflict!

I was calling a C++/CLI dll from C#; the C++/CLI library is a wrapper around a third party native dll.

Turns out I had two dlls with the same name, both in the path (libeay32.dll).

In order to discover the source of the problem I installed the windows debugging tools: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools Old link: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

Run 'gflags' (in the "c:\Program Files\Debugging Tools . . ." folder) in order to enable display of loader "snaps"

i.e.

> gflags -i <my test app.exe> +sls

then run the app in cdb (console debugger) or windbg and trawl through the output to find out which dll caused the exception.

e.g. 

> cdb -g <my test app.exe>

Renaming the 'wrong' libeay32.dll demonstrated the problem but is only a temporary solution!

The same fault-finding approach might work for you anyway.

answered on Stack Overflow Jul 15, 2010 by CJBrew • edited Apr 2, 2019 by kfreezen
▲
2
▼

Given your usage of native code here I think the most likely problem here is that you are attempting to load a native DLL as if it were a .Net assembly. This is one scenario which will spawn an BadImageFormatException.

Try running your application and set it to break on throw for BadImageFormatException and see what DLL is being loaded. If it's a native one then that's the problem.

answered on Stack Overflow Mar 22, 2010 by JaredPar
▲
0
▼

In my case, turning off Enable unmanaged code debugging in Debug tab of EXE's project properties ironically did the trick, if it's checked.

To be honest, I am not sure why that is the cause of the problem though.

answered on Stack Overflow Aug 7, 2013 by Tae-Sung Shin

User contributions licensed under CC BY-SA 3.0