BadImageFormatException when loading 32 bit DLL, target is x86

Question

I have a DLL (FreeType) which is certainly 32-bit (header: IMAGE_FILE_MACHINE_I386).

I want to use it from C# code, using DllImport.

Target of my application is x86, IntPtr.Size is 4, process is 32-bit.

But I get BadImageFormatException (Exception from HRESULT: 0x8007000B). What can be wrong?

Of course I use 64-bit Windows 7.

Calyptrogen

Voting to close as 'not a real question' -- the basis for the question was a misunderstanding; the OP found the DLL in question was loading correctly – Carny

Answer 1

From what I understand, an assembly specifically built for x86 and running in a 64-bit operating system can only load libraries built for x86 or a BadImageFormatException will be thrown. In a 64-bit OS, an assembly built for Any CPU or x64 will throw the same exception when trying to load an x86 library.

So, assuming nothing incredibly weird is going on, I would ensure that you've set your application to build as x86 by opening the project properties and clicking on the Build tab. Ensure 'Platform Target' is set as 'x86' and not Any CPU.

Alternatively, you could try to find a 64-bit version of the DLL for testing purposes.

Bruell

I am 100% sure that my C# app is 32-bit. I even used CORFLAGS to check it: Version : v2.0.50727 CLR Header: 2.5 PE : PE32 CorFlags : 3 ILONLY : 1 32BIT : 1 Signed : 0 – Calyptrogen

@Eric Smith I was having the same issue...this fixed it. Thank you so much! – Schluter

Yes, and the same thing happens the other way around. For example, if a 64-bit app attempts to load a 32-bit DLL. – Rajiv

Answer 2

Recompile the dll with the option "Any CPU" in Build -> Platform.

Barkentine

Any CPU is not in the list for me. – Tanner

Answer 3

OK, seems like a false alert. It was not related to bitness, there was just other DLL missing that freetype depends on. However error messages could be more helpful.

Calyptrogen

This half solved my problem with BadImageFormatException - I forgot to copy over the dependent DLLs. Unfortunately now I get DllNotFoundException on the original DLL... – Madeline

@Madeline make sure you built Release version (not Debug) – Julee

Answer 4

Got the same error when calling a 64-bit C Dll from C#. I had to manually change C# Properties->Build->Platform target from Any Cpu to x64. Apparently Any Cpu is sometimes NoCpu.

Tideland

Answer 5

Besides, for web-application needs resolve to run 32-Bit Applications in IIS 7. See http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html

Dithionite

Answer 6

I had a similar error. I could solve it by adding the ucrtbase.dll or ucrtbased.dll for debug as well as the vcruntime140.dll or vcruntime140d.dll for debug into the directory of the executable. I think the 140 depends on the version number of Visual Studio you are using.

ucrtbase.dll usually lies in C:\Windows\System32. vcruntime140.dll lies in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86\vcruntime140.dll

You can find more information here: http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

Kwei

Answer 7

I suspect the common cause of this exception has changed in the 8 years since the question was first asked. On my setup using VS 2017 I found that unchecking "Prefer 32-bit" solved the issue:

Uncheck "Prefer 32-bit" in the Build options

This made my 64-bit DLL built from C++ load correctly. Conversely, checking this option should make 32-bit DLLs load correctly.

Renter

Answer 8

When you build a native application/DLL something with Visual Studio, it gains a dependency on the "redistributable" package for that version of Visual Studio. That contains DLLs like msvcr100.dll and msvcp100.dll (for various values of 100).

In my case, I had seen those DLLs in the target machine's Windows/system32 directory, so I thought all was well. It turns out that those DLLs were x64! I have no idea why a directory called system32 contains 64-bit DLLs. So I searched my Visual Studio 2010 directory for everything named msvc*.dll, and found x86 versions of msvcr100.dll and msvcp100.dll. I copied those to the target machine (in a place accessible from my program's path) and all was well.

I hope this helps someone else confronted with Microsoft's sheer madness.

Clipping

Answer 9

you use Properties in C# project, and change "Platform target" to x64. enter image description here

Doe

Answer 10

You can try check the option "Properties" -> "Build" -> "Allow unsafe code".

Pronunciamento

Answer 11

You have to look at the dependents of the DLL, since one of the dependents may use a 64 bit DLL which makes it incompatible with your project. visual studio -> tools -> command line -> powershell

dumpbin /dependents your_dll_file.dll and check these dll's and find out which one is actually not the same with your dll.

Chucklehead

Answer 12

I had the same Exception in MS Visual C# Express 2010. I checked all build .dll and .exe files with Dependency Walker and MiTeC EXE Explorer, everything was build for 32bit!

In the end, it was the following line missing in my .csproj file:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'MY_CONFIG|x86'">
    ...
    <PlatformTarget>x86</PlatformTarget>
    ...
</PropertyGroup>

I don't know why it was missing ... I guess MS Visual C# Express 2010 is not bugfree ;)

Bellarmine