Common Issues with 32-bit Applications Failing on 64-bit

In most cases, 32-bit applications execute with no issues on 64-bit thanks to WOW64. However, there are a few cases that you may need to make modifications to your application in order for it to work on 64-bit.  I’ll cover the common issues and possible solutions in this post.

64-bit OS Basics

32-bit kernel mode drivers will not load. Kernel mode drivers must match the OS. If your application is dependent on a driver, you will need a 64-bit version of the driver.	Compile or obtain a 64-bit version of the driver. Install the version of the driver that matches the OS.
64-bit kernel mode drivers must be signed. Unsigned 64-bit drivers will not be loaded at boot time.	You must sign your driver or obtain a signed driver if it’s 3rd-party. Test signed drivers can be loaded in test mode. This is intended for development only.
The 16-bit subsystem is removed on a 64-bit OS. Applications compiled for 16-bit will not execute. This generally affects legacy 16-bit installers.	16-bit executables must be replaced with a 32-bit or 64-bit version of the executable.
Registry reflection between the 64-bit and 32-bit hives has been removed on Windows 7. Keys are now either redirected or shared.	Do not depend registry reflection to synchronize state between 32-bit and 64-bit applications. More info.
I’ve saved the best for last. This is the most common problem we see: 32-bit binaries cannot be loaded into a 64-bit process and vice versa.	Verify executables and dependent libraries are compiled to target the same processor (e.g. x86 or x64).

 

 

Why does my .NET Application Compiled as “AnyCPU” fail with a BadImageFormatException on a 64-bit OS?

The last issue mentioned in the table above is a very common scenario with .NET applications on 64-bit.  I’m going to step through the specific issue in more detail.  In this scenario, the application is compiled as “AnyCPU”.  This is the default setting for a .NET project.  On 64-bit, the application will use the 64-bit runtime.  If a referenced library is compiled to target 32-bit only, it will not load into the 64-bit process. Therefore, you get an error similar to this:

BadImageFormatException was unhandled. Could not load file or assembly… An attempt was made to load a program with an incorrect format.

We solve this problem by matching the application “bitness” with the library. You need to make sure the application and all the dependent libraries target the same processor. e.g. “AnyCPU” or “x86”. If you have the option to recompile, make sure all your projects match. If you can’t recompile, you can use corflags.exe to change the header (See Chris’ post).

I hope this helps with getting your apps running on 64-bit.  As always, the AppCompat cookbooks are a good reference. Here are links to the 64-bit compatibility sections:  Application Compatibility: Windows Vista 64-Bit, Removal of Windows Registry Reflection

Comments

• Anonymous
  August 07, 2015
  I have been using MS Excel 32 bit on Windows 7 Pro 64 bit OS and not a day goes by when I run into either "cannot paste data" or "too may cell formats" errors or excel crashes. I never had this problem when running excel 32 bit on 32 bit OS - NEVER. Now - working with same data, doing same data ops - every day the above probs are encountered. If I close the workbook and reopen, I can paste data without prob for a short amount of time.