BadImageFormatException when loading 32 bit DLL, target is x86

Question

BadImageFormatException when loading 32 bit DLL, target is x86

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.

c#

dll

dllimport

32bit-64bit

badimageformatexception

asked on Stack Overflow Apr 28, 2010 by

Coder

11 Answers

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.

answered on Stack Overflow Apr 28, 2010 by

Eric Smith

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

enter image description here

answered on Stack Overflow Jun 24, 2013 by

RckLN • edited Jun 24, 2013 by

RckLN

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.

answered on Stack Overflow Apr 28, 2010 by

Coder

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

answered on Stack Overflow Oct 17, 2012 by

Anastacia

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.

answered on Stack Overflow May 14, 2016 by

BSalita

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

answered on Stack Overflow Jan 21, 2016 by

Peter Ittner

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.

answered on Stack Overflow Feb 26, 2018 by

Caleb

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.

answered on Stack Overflow May 5, 2017 by

ulatekh

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

answered on Stack Overflow Jun 20, 2018 by

xuanbka1

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

answered on Stack Overflow Dec 13, 2013 by

ADM-IT

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 ;)

answered on Stack Overflow May 6, 2013 by

Jane

User contributions licensed under CC BY-SA 3.0