Click here to Skip to main content
15,867,686 members
Articles / 64 bit

99 Problems and a Bit Ain’t One

Rate me:
Please Sign up or sign in to vote.
0.00/5 (No votes)
20 Oct 2014CPOL2 min read 7.3K   1
99 Problems and a Bit Ain’t One

99Problems

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

When encountering this issue, you'll undoubtedly toggle between x64, x86 and the Any CPU options. Success may vary by user.

When encountering this issue, you’ll undoubtedly toggle between x64, x86 and the Any CPU options. Success may vary by user.

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:

1. Open up your Available Applications pools within IIS

AppPool

2. Right-click on the Application Pool that houses your troubled Application and choose the “Advanced Properties” option

ApplicationPoolAdvanced

3. Set the “Enable 32-Bit Applications” option to “True”

Enable32BitApplications

4. Finally, restart / recycle your Application Pool for these changes to go into effect.
Recycle

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 over 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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer (Senior)
United States United States
An experienced Software Developer and Graphic Designer with an extensive knowledge of object-oriented programming, software architecture, design methodologies and database design principles. Specializing in Microsoft Technologies and focused on leveraging a strong technical background and a creative skill-set to create meaningful and successful applications.

Well versed in all aspects of the software development life-cycle and passionate about embracing emerging development technologies and standards, building intuitive interfaces and providing clean, maintainable solutions for even the most complex of problems.

Comments and Discussions

 
SuggestionSolutions, without much background explanation Pin
John Brett21-Oct-14 1:20
John Brett21-Oct-14 1:20 
Whilst the solutions will work in many cases, I don't feel that this article goes into enough explanation about why the problem arises in the first place.

I was hoping for some sort of compatibility matrix, or even just the simple rules governing processor architecture. E.g.
Exe architectureCPU architectureRuntime architecture
323232
6432fail
il3232
326432
646464
il3264


Once the executable has defined the runtime architecture, then only compatible dlls may be loaded
Runtime architectureDLL architectureLoads?
3232yes
6432fail
32ilyes
64ilyes
3264fail
646464


It's also important to know what constraints you have in the system. If everything's built to AnyCPU then the program will run fine as a 32 bit app on a 32 bit system, and as a 64 bit app on a 64 bit system.
However, if any component of the system has to run as 32 bit (old .DLLs, .DLLs written in C++, COM objects), then the application needs to be launched as a 32 bit app and the components will load. You can't then have a component that only runs as 64 bit, of course.

John

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.