Tip of the day: "An attempt was made to load a program with an incorrect format" .NET P/INVOKE issue

The other day I was using a 3rd party utility which was built on the .NET platform. My primary work computer happens to be a x64 installation. So on this computer when I fired the utility up, and tried to perform some tasks it would error with a .NET Exception which basically had the following characteristics:

- Message: "An attempt was made to load a program with an incorrect format"

- Exception: System.BadImageFormatException

After some troubleshooting it turned out that this utility was trying to load a plain-old DLL (which exported some functions) presumably using P/Invoke. The DLL was built for 32-bit platforms. Now it turns out that by design a 64-bit process (the 3rd party utility would run as a 64-bit process owing to the 64-bit .NET runtime) would be prevented from loading a non-COM 32-bit DLL (32-bit COM DLLs are loaded in a DLLHOST.EXE surrogate when invoked from a 64-bit client process, BTW...) with the above exception.

To configure the utility to run as a 32-bit .NET process, it turns out you can use the CORFLAGS utility. You run it as follows to switch the 32-bit execution mode ON:

corflags utility.exe /32Bit+

To turn it off, just use /32Bit- in the above command line.

Comments (15)

  1. Thanks for the info.

    I got this error whilst debugging a Winform application using Visual Studio 2008.

    The Winform referenced an assembly that must have been compiled with the "x86" option.

    To fix the problem I went to the compile properties of my project and chose "x86" as the cpu target, as opposed to "Any".

    Just thought others would like to know.

  2. Tim says:

    Great Tips here guys, thanks very much

    Helped me out with the compile properties thing.  Was using Expression Encoders in a Windows Service but the DLLs are all x86 only so it was failing

    Thanks for your help :¬)

  3. Just started to look into running the our product on Server 2008 R2.

    Spent most of the day with the hope of running our product without a mod and without talking to the DICOM library vendor was almost none.

    The found this article!

    Also found CorFlags on my dev machine with VS 2008 installed, and quickly applied the suggested fix.

    Now we are ecstatic!!!

    Thank you for this information, our p/Invoke now works and DICOM images are flowing.

  4. Phil says:

    Your a star.

    Thanks for the good tip.

  5. Don says:

    Thanks to Julian Biddle – I was getting this error and changing the target platform to x86 worked a treat.

  6. Richard B says:

    Thanks to Julian Biddle from me too – changing to x86 sorted it!

  7. Arturo Estigarribia says:

    Change to x86, solve the problem. THANKS A LOT!, muchas gracias compañero, te debo una.

  8. Ali Rajab says:

    Thanks for saving my time

  9. Blaine says:

    I get the message "an attempt was make to load a program with an incorrect format" when I try to save a picture from a website to my laptop. I am not a power user as the others on this thread appear to be. I need some more basic step-by-step directions to help me solve this issue.

  10. Hi Blaine, the symptoms seem very different in your case. Please contact your nearest administrator to investigate this further.

  11. srikanth says:

    c:WindowsMicrosoft.NETFrameworkv4.0.30319Microsoft.Common.targets (1360): Could not resolve this reference. Could not locate the assembly "Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

  12. Nishant says:

    I have an Issue on Windows 7 I have all the Dll's compiled under "Any CPU" and 2 DLL compiled under "x86" …it was working fine..but I have moved my code to Windows Server 2012, I am getting the same error….Any help will be appreciated….

  13. Nishant, most probably your Windows 7 machine was 32-bit. Windows 2012 is x64-only. So what must be happening is that the 'Any CPU' DLL will now manifest as 64-bit while the other 2, which are compiled as 32-bit only, will not be loaded due to the incompatibility. Please use CORFLAGS to adjust the same as described in my above article.

  14. rauHolle says:

    I was writing a minimal DLL in C++ which I integrated in a minimal C# console application and got the same error that you stated above. However both tricks listed here did not fix it. The final fix is simple: Your target PC might not have the appropriate VS redistributable package installed. In my case (VS 2013) it was this one here: http://www.microsoft.com/…/details.aspx for some reason it does not work to copy the required DLLs from the system32 folder manually… what a freak bug taking me half a day to find out. I did not find this anywhere online, will do some cross-posting now…

Skip to main content