If you have ever worked on a project that involves interactions between 32-bit and 64-bit applications and referencing their DLLs, you may have encountered this guy before:
BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
This nasty BadImageFormatException generally stems from referencing legacy libraries (or any libraries containing unmanaged code) that were not really designed to run on 64-bit machines.
If your all of the code within your 32-bit libraries is managed, then you should be just fine and you shouldn’t see much of this guy at all. This post will cover two methods for hopefully resolving this issue using configuration features available in both Visual Studio and within IIS.
Troubleshooting this Issue
When running into this, I’m sure that your first instinct will be to toggle through the various settings within your Project / Solution regarding its Build target. You’ll probably switch back and forth from x86 (32-bit) to x64 (64-bit) and attempt to re-build and run your application countless times:
![build]()
Then you’ll likely say “well the Any CPU setting should work” and you’ll try that, only to again be met with the same error that you encountered previously. This isn’t always the case, as I have found that one of these settings may occasionally work, but success may vary by user and application.
Resorting to IIS
If tinkering with the available settings and targets within the Build tab of your Solutions properties didn’t help, you might need to pull out the bigger guns and try to handle this at the Application Pool level in IIS. Try opening up the IIS Manager that your application is targeting and go through the following steps :
- Open up your Available Applications pools within IIS :
![pools]()
- Right-click on the Application Pool that houses your troubled Application and click the Advanced Properties option :
![option]()
- Set the Enable 32-Bit Applications option to True :
![option]()
- Restart / recycle your Application Pool for these changes to go into effect :
![pool]()
I’ve found that this should fix the issue a majority of the time, however there are performance considerations that you might want to review prior to making this change, the primary one being memory availability / access to a much larger possible memory space. If you are using this approach, you might want to consider reading through this related Stack Overflow discussion on using this setting within IIS to get an idea of a few other possible side-effects.
More Information
If you want to learn a bit more about how 32-bit and 64-bit processes interact with one another within the CLR, I would encourage you to give Scott Hanselman’s post on this same issue a read. Scott describes the article as “obscure”, but again, if it is something that you are interested in, it’s certainly worth a read and goes into quite a bit of depth.
Read more articles on .NET: