"An attempt was made to load a program with an incorrect format" even when the platforms are the same


I'm calling functions from a 32-bit unmanaged DLL on a 64-bit system. What I get is:

BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

At first, I had my projects set to the Any CPU platform, so I changed them both to x86, but this error is still occurring. That's really the only fix I know for this.

The DLLs aren't corrupt or anything, because I can use them with other programs (that I don't have the source to). I thought that perhaps it wasn't finding a dependency, but I checked and they're all there. Plus, wouldn't it throw a DllNotFoundException in that case?

What else can I do? And before you say "Use a 64-bit unmanaged DLL instead," let me point out that there isn't one. ;)

asked on Stack Overflow Jan 7, 2010 by David Brown • edited Jan 7, 2010 by David Brown

20 Answers


If you try to run 32-bit applications on IIS 7 (and/or 64-bit OS machine), you will get the same error. So, from the IIS 7, right click on the applications' application pool and go to "advanced settings" and change "Enable 32-Bit Applications" to "TRUE".

Restart your website and it should work.

enter image description here

answered on Stack Overflow Jan 6, 2011 by bluwater2001 • edited Feb 19, 2014 by viggity

Somehow, the Build checkbox in the Configuration Manager had been unchecked for my executable, so it was still running with the old Any CPU build. After I fixed that, Visual Studio complained that it couldn't debug the assembly, but that was fixed with a restart.

answered on Stack Overflow Jan 8, 2010 by David Brown

In Visual Studio, Right Click your project -> On the left pane click the Build tab,

Project properties, build tab

under Platform Target select x86 (or more generally the architecture to match with the library you are linking to)

Project properties, platform target

I hope this helps someone! :)

answered on Stack Overflow Oct 21, 2013 by Marvin Thobejane • edited May 14, 2015 by Marvin Thobejane

If you encounter this error when you click green arrow button to run the application, but still want to run the app in 64 bit. You can do this in VS 2013, 2015, 2017, and 2019

Go to: Tools > Options > Projects and Solutions > Web Projects > Use the 64 bit version of IIS Express

answered on Stack Overflow Jul 5, 2016 by paibamboo • edited Jan 31, 2020 by paibamboo

I just had this problem also. Tried all the suggestions here, but they didn't help.

I found another thing to check that fixed it for me. In Visual Studio, right-click on the project and open "Properties". Click on the "Compile" (or "Build") tab and then click on "Advanced Compile Options" at the bottom.

Check the dropdown "Target CPU". It should match the "Platform" you are building. That is, if you are building "Any CPU" then "Target CPU" should say "Any CPU". Go through all of your Platforms by making them active and check this setting.

answered on Stack Overflow Dec 12, 2011 by Denis • edited Jul 23, 2019 by fridoo

If you are using Any CPU, you might encounter this issue if the Prefer 32-bit option is checked:

Make sure you uncheck this option in the project's property's Build tab!

enter image description here

answered on Stack Overflow Sep 24, 2013 by Drew Noakes • edited Aug 23, 2017 by Denis

In my case I was using a native DLL in C#. This DLL depended on couple of other DLLs that were missing. Once those other DLLs were added everything worked.

answered on Stack Overflow Dec 11, 2012 by Tomasz Stypich

A bit off topic for this post, but searching for this error message brought me here.

If you are building through team system and getting this error, the build definition process tab has a "MSBuild Platform" setting. If this is set to "Auto", you may experience this problem. Changing it to "X86" can also resolve the error.

answered on Stack Overflow Oct 5, 2012 by StingyJack

Building on the answer of @paibamboo

He said: Go to: Tools > Options > Projects and Solutions > Web Projects > Use the 64 bit version of IIS Express

My coworker had this box checked (he explicitly looked for it), but had the error message in question. After some hours he unchecked the box and checked it again. Lo and behold: The code now ran with success.

It seems, that there are two places where the state of this box ist saved which became out of sync. Un- and rechecking it synced it again.

Question for more knowledgable users: Was there an update or something last week (for VS 2015) which de-synced the states?

answered on Stack Overflow Oct 16, 2017 by MilConDoin

We had a similar issue and we managed to fix it by setting the Platform target to x86. Project Properties-> build

answered on Stack Overflow Aug 19, 2019 by Joe

Also see this answer, which solved the same problem for me.

Posted by Luis Mack on 5/12/2010 at 8:50 AM I've found the same problem, only for a specific project when compiling on a 64-bit machine. A fix that SEEMS to work is to manually alter one character in the image stream EVERY TIME the usercontrol or form is edited in the designer


Change to


That is 00LjAuMC4w back to 0yLjAuMC4w at the end of the line (00 back to 0y)

answered on Stack Overflow Mar 21, 2012 by Shaul Behr • edited Jun 20, 2020 by Community

1:Go to: Tools > Options > Projects and Solutions > Web Projects > Use the 64 bit version of IIS Express 2: change below setting for web service project. enter image description here

answered on Stack Overflow Apr 30, 2020 by Mani

In my case, I am using a tiny .exe that reloads the referenced DLLs via Reflection. So I just do these steps which saves my day:

From project properties on solution explorer, at build tab, I choose target platfrom x86

answered on Stack Overflow Feb 15, 2012 by asdf_enel_hak

In my case, I was running tests through MSTest and found out that I was deploying both a 32-bit and 64-bit DLL to the test directory. The program was favoring the 64-bit DLL and causing it to fail.

TL;DR Make sure you only deploy 32-bit DLLs to tests.

answered on Stack Overflow May 7, 2015 by Mike Cluck

With Visual Studio 2019 I had a similar issue when I wanted to run tests (MSTest directly from VS). In my case I only had an x64 native DLL and I received this error message. First, I thought it is because Visual Studio runs as x86 but this page helped me to solve the issue:

Run unit test as a 64-bit process

It says

  1. Set your projects to Any CPU
  2. Explicitly define processor architecture

I did both (I explicitly set x64) and then my tests started to work.

Set processor architecture explicitly to x64

answered on Stack Overflow Aug 29, 2020 by luviktor

I got this issue solved in the 'Windows' way. After checking all my settings, cleaning the solution and rebuilding it, I simply close the solution and reopened it. Then it worked, so VS probably didn't get rid of some stuff during cleaning. When logical solutions don't work, I usually turn to illogical (or seemingly illogical) ones. Windows doesn't let me down. :)

answered on Stack Overflow Apr 30, 2013 by user1771386

I was able to fix this issue by matching my build version to the .NET version on the server.

I double clicked the .exe just to see what would happen and it told me to install 4.5....

So I downgraded to 4.0 and it worked!

So make sure your versions match. It ran on my dev box fine, but server had older .NET version.

answered on Stack Overflow Dec 16, 2015 by Nateous

In my case it was wrong content of the file. DLL was downloaded from the web, but content of the DLL was HTML page :D Try to check if it is binary file, if it seems like correct DLL :)

answered on Stack Overflow Jun 22, 2016 by Ludwo

We were having the same issue in .NET core. The solution was to download 32-bit .netcore runtime, and having your project target x86

In your csproj file add


    <RunCommand Condition="'$(PlatformTarget)' == 'x86'">$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>    

This was used for a Windows machine, you'd have to adjust paths and such for Linux/OSX

answered on Stack Overflow Jun 27, 2019 by Samir Banjanovic

If you are importing unmanaged DLL then use

CallingConvention = CallingConvention.Cdecl 

in your DLL import method.

answered on Stack Overflow Oct 10, 2019 by Ramkumar Shanmugam

User contributions licensed under CC BY-SA 3.0