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

Question

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

What projects did you change to x86? And how do you execute them when you get the exception, through the debugger or manually? If the latter, did you notice that when you changed to x86, you got a new folder in your bin\ directory? It's basically now bin\x86\Debug for the files. — Lasse V. Karlsen, Jan 07 '10 at 21:30
Can you verify that the executable is running in 32-bit mode (*32 in the process manager)? — JP Alioto, Jan 07 '10 at 21:31
@Lasse V. Karlsen: Yeah, I removed the x86 bit from the output path when I changed the platform in each project. My first project is a DLL that wraps the functions in the unmanaged DLL. The second project is an executable that uses the wrapper in the first DLL. Both are set to x86. — David Brown, Jan 07 '10 at 21:37
@JP: Actually, the process manager doesn't show it to be running as a 32-bit process. Why is that? — David Brown, Jan 07 '10 at 21:37

score 585 · Answer 1 · edited Feb 19 '14 at 19:52

585

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

edited Feb 19 '14 at 19:52

viggity

15,039
7
88
96

answered Jan 06 '11 at 20:08

bluwater2001

7,829
5
24
21

1

Oh my days I've been fishing around installing extra IIS components when this was the answer... Can anyone suggest a downside to having this option selected? – notidaho Jul 31 '12 at 14:10
3

Here's a good discussion on the question of performance regarding this: http://stackoverflow.com/questions/507820/what-are-the-pros-and-cons-of-running-iis-as-32bit-vs-64bit-on-a-64bit-os – Ben Power Nov 23 '12 at 01:16
I have a problem with SharpSvn and this doesn't help. :( Sth is very wrong with this assembly I tell you... – user2173353 Nov 05 '13 at 08:22
12

This answer is a wtf for me, because the question doesn't mention IIS at all! – kristianp Nov 04 '16 at 02:51
I think something to keep an eye on is when you do change it 'True' it might remove the added 'Applications' which you will have to add again. – Saumil Jun 26 '20 at 16:17
I faced the opposite problem. So if you are seeing this issue with "Enable 32-Bit Applications" already set to "True", try setting to "False" instead. – srk Jul 26 '22 at 19:27

score 151 · Accepted Answer · answered Jan 08 '10 at 01:59

151

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 Jan 08 '10 at 01:59

David Brown

35,411
11
83
132

1

Thanks a lot. This got me too. Checked build in Configuration Manager and now it works (WPF desktop application). – Dan Gøran Lunde May 24 '13 at 10:30
1

If you've done all the above, and checked your platform setting, build configuration settings, cleaned the solution and it's still not working - search for all instances of the DLL and delete them. – Will Calderwood Aug 06 '13 at 15:15
with VS 2015 this is still valid - although I didn't need to restart :) – increddibelly Dec 04 '15 at 13:18
That's it! Re-visit your Configuration Manager settings is the answer. – AndyUK Jun 05 '17 at 09:31

Marvin Thobejane · Answer 3 · 2023-07-25T06:00:15.340

104

In Visual Studio, Right Click your project and select properties -> 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

edited Jul 25 '23 at 06:00

answered Oct 21 '13 at 07:35

Marvin Thobejane

2,010
1
19
13

2

This fixed my issue in VS2013, I found an alternative fix is to leave "Platform target" as "Any CPU" but check the "Prefer 32-bit" check box. – user1069816 May 13 '15 at 09:50
2

Although you need to be using .NET 4.5 or higher to be able to check the "Prefer 32-bit" check box – user1069816 Jul 30 '15 at 12:35
1

Yes, but I converted my project in 'Any CPU' to 'x64'. My 32 bit project working fine but the same code I converted to 64 bit, that project not working fine as 32 bit. Can you please give me the proper 64 bit conversion process... – Ismayil S Aug 16 '18 at 13:04
@IsmayilS make sure you're using a 64-bit version of the library you're linking to – Marvin Thobejane Sep 13 '18 at 09:19
I upgraded to VS2022 and for some reason 1 project switched the platform target to x86. Even though the solution manager shows Any CPU, it was still trying to compile to x86. – Roger Far Jan 06 '22 at 15:48
1

Title should read: "In Visual Studio, Right click on your project and select Properties, -> On the left...." – Leo Jul 20 '23 at 12:35

score 92 · Answer 4 · edited Sep 10 '21 at 15:50

92

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

Or you can do it per project at Project Properties > Web > Bitness

edited Sep 10 '21 at 15:50

Adam Nofsinger

4,004
3
34
42

answered Jul 05 '16 at 13:46

paibamboo

2,804
17
16

5

Thanks. I tried so many and nothing helped. You are my life saver. I have 64bit OS, installed a 64 bit Visual studio [which still runs as 32bit for unknown reason]. When I put my Platform Target to x64, it was throwing error BadImageFormatException. With your fix, it worked. I gave you an upvote. You rock – Nathan Mar 12 '18 at 15:46
I'm glad I could help :) – paibamboo Mar 13 '18 at 01:24
This is the answer I need. Thanks a lot! – yushulx Apr 28 '18 at 06:54
Thanks a lot, this solved the problem. It works well with Visual Studio 2017 32-bit process. – samir105 May 27 '18 at 06:02
with above setting only it was not working, I did one ore change in a project setting – Mani Apr 30 '20 at 06:30
Hooorahhhh! I will save this tip to my knowledge box for the future. Thanks! This worked for my Web API that had to reference a DLL that ran only in x64. – Manuel Plaza Aug 15 '20 at 02:57
This worked for me. Thanks! – Moruling James Jan 17 '22 at 06:46

score 57 · Answer 5 · edited Jul 23 '19 at 15:49

57

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.

edited Jul 23 '19 at 15:49

frido

13,065
5
42
56

answered Dec 12 '11 at 19:13

Denis

11,796
16
88
150

2

And for those of us just using the compiler, my fix was to add "/platform:x86" to the compiler flags. – Urchin Apr 18 '13 at 20:26
This fixed it for me as well. I had to adjust the "platform target" on the "Build" tab. – Jowen Nov 13 '13 at 13:43
if you're on 64 bit, also check the "prefer 32 bit" flag. I had to disable it for me. – N4ppeL Apr 16 '19 at 09:58
I found that opening the project settings, going to the Build tab and setting General / Platform target: Any CPU worked for me. For some reason I didn't need to do it for all the projects in the solution. I'm using VS2022. – Skyfish Aug 22 '23 at 15:27

score 44 · Answer 6 · edited Aug 23 '17 at 14:43

44

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!

edited Aug 23 '17 at 14:43

Denis

11,796
16
88
150

answered Sep 24 '13 at 13:55

Drew Noakes

300,895
165
679
742

3

It would be helpful if you could indicate where in Visual Studio to find this option. – trysis Aug 26 '14 at 14:43
@trysis, this option is in the _Build_ page of the project settings pane. – Drew Noakes Aug 26 '14 at 16:16
1

I was saying it would be helpful to put it in. As this answer stands, there is no context to tell the hapless, possibly new user of StackOverflow where to find it. – trysis Aug 26 '14 at 16:20
What is the path for get this form? I can't find it – Adolfo Correa Oct 01 '17 at 19:06
In Visual Studio, right click the project and choose 'Properties'. – Drew Noakes Oct 01 '17 at 19:59

score 19 · Answer 7 · answered Dec 11 '12 at 20:30

19

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 Dec 11 '12 at 20:30

Tomasz Stypich

221
2
3

2

This answer is hidden between all repeating solution for checking 'target architecture'. This answer should stand out more as it presents a new idea (which lead for my case to the resolution). – Stefan Jul 06 '22 at 13:20

score 10 · Answer 8 · edited Apr 01 '22 at 18:57

10

Go to: Tools → Options → Projects and Solutions → Web Projects → Use the 64 bit version of IIS Express.
Change below setting for web service project:

edited Apr 01 '22 at 18:57

Timothy G.

6,335
7
30
46

answered Apr 30 '20 at 06:33

Mani

335
2
10

1

Was the simple answer to the problem presented. Worked for me. – ransems Jul 08 '20 at 12:31

score 9 · Answer 9 · answered Aug 19 '19 at 02:34

9

We had a similar issue and we managed to fix it by setting the Platform target to x86.

answered Aug 19 '19 at 02:34

Joe

349
2
3

So x86 dlls are different from x64? Is there a way to detect this on a referenced dll file? – NoBugs Nov 01 '19 at 04:56
@NoBugs Looks like you can. Have a look at this [thread](https://stackoverflow.com/questions/270531/how-to-determine-if-a-net-assembly-was-built-for-x86-or-x64) – Joe Nov 01 '19 at 06:14

score 8 · Answer 10 · answered Oct 05 '12 at 13:55

8

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 Oct 05 '12 at 13:55

StingyJack

19,041
10
63
122

this is the closest answer to what i was experiencing. I had a dll that had to be x86. I used it in another project , which was AnyCPU by default. They just need to match. In this case, it didnt make much difference, so I changed the new project to x86. – greg Jan 24 '14 at 22:34

score 8 · Answer 11 · answered Aug 29 '20 at 09:04

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

Set your projects to Any CPU
Explicitly define processor architecture

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

Nice one. This is going to help a few people in my department. Now we just have to sort why. — ouflak, May 25 '21 at 14:10

score 4 · Answer 12 · answered Jun 22 '16 at 07:42

4

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 Jun 22 '16 at 07:42

Ludwo

6,043
4
32
48

Exactly the same – MorganR Mar 17 '23 at 22:48

score 4 · Answer 13 · answered Oct 16 '17 at 14:42

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?

score 3 · Answer 14 · edited Jun 20 '20 at 09:12

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
 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w
Change to
 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w
That is 00LjAuMC4w back to 0yLjAuMC4w at the end of the line (00 back to 0y)

score 2 · Answer 15 · answered May 07 '15 at 19:30

2

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 May 07 '15 at 19:30

Mike Cluck

31,869
13
80
91

score 2 · Answer 16 · answered Oct 10 '19 at 10:31

2

If you are importing unmanaged DLL then use

CallingConvention = CallingConvention.Cdecl

in your DLL import method.

answered Oct 10 '19 at 10:31

Ramkumar Shanmugam

81
10

score 2 · Answer 17 · answered Feb 15 '12 at 09:21

2

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 Feb 15 '12 at 09:21

asdf_enel_hak

7,474
5
42
84

score 1 · Answer 18 · answered Apr 30 '13 at 09:38

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. :)

score 1 · Answer 19 · answered Dec 16 '15 at 21:58

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.

score 1 · Answer 20 · answered Jun 27 '19 at 20:28

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

  <PropertyGroup>
    <PlatformTarget>x86</PlatformTarget>  
  </PropertyGroup>

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

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

score 0 · Answer 21 · answered Mar 31 '21 at 23:48

0

In my case, I didn't have the correct project set as the start-up project. I went to solution settings and selected the correct startup project and it worked

answered Mar 31 '21 at 23:48

Conner

352
4
10

score 0 · Answer 22 · answered Jun 29 '21 at 08:17

0

In my case this same error happened after publishing. I had published before with another platform configuration.

The solution was to cleanup the publish folder first, then it worked.

(alternatively set the "delete existing files" option to true)

answered Jun 29 '21 at 08:17

Allie

1,081
1
13
17

score 0 · Answer 23 · answered Dec 01 '21 at 13:24

0

Another reason that may cause this exception, is the C++ Redistributables missing for the target platform of your Dll. I had a tough time finding out when testing on a VM.

answered Dec 01 '21 at 13:24

crankedrelic

463
1
5
14

score 0 · Answer 24 · answered Feb 07 '22 at 11:33

0

For .net core, make sure Ijwhost.dll is in the output directory, sometimes it isn't being copied and this will cause the error. See https://github.com/dotnet/runtime/issues/38231 and also https://stackoverflow.com/a/58773266/9665729

answered Feb 07 '22 at 11:33

Neo

474
6
13

score 0 · Answer 25 · answered May 18 '22 at 08:06

Please also note that the version of used dll file(s) (in my case "WebView2Loader.dll") which is in use is very crucial. I had almost the same problem with "Microsoft.WebView2.FixedVersionRuntime.101.0.1210.39.x64" when I tried to use the WebView2 component in the MMC Snap-Ins with types of "HTMLView" or "FormView".

I just copied the referenced dll file in a proper path that was accessible for the project (you could just put it beside your project output files first to test it) and then WebView2 browser started to function as expected. Microsoft error messages sometimes (at least in my case) was a little bit misleading and did not convey enough and to the point information.

I received "BadImageFormatException" that normally occurs when you mix platform targets (for example using a dll file compiled in X64 in an application that targeted for x86 or vice versa) or mix native code and .NET but that was not my problem at all. I hope this help one who may stuck in.

score 0 · Answer 26 · edited Aug 02 '22 at 16:48

0

I also had this issue when I want to call a native DLL from C#/WPA. The below steps work for my project. Properities->Build->Platform target x64/x86(change this option, then works).

edited Aug 02 '22 at 16:48

lee-m

2,269
17
29

answered Jul 31 '22 at 14:04

GuangJun Liu

39
7

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

26 Answers26

Linked

Related