Disclaimer: This is not an exotic edge case or even a particularly difficult bug to figure out. I am merely writing about it because I managed to learn a few useful things about how .NET works in a 64 bit environment as I was investigating it and thought it might be useful to share.
The Bug: We recently upgraded one of our desktop apps from .NET 1.1 to 3.5 and our tester reported that it immediately crashed during start-up on a 64-bit machine (both XP and Vista). There were no problems with it prior to the upgrade and it still worked fine on 32 bit machines (…or rather, it did after we fixed all the cross-threading exceptions). The event viewer only showed a rather unhelpful unhandled exception in the Kernel32.dll (exception code 0xe0434f4d).
The Mystery: Why would upgrading an app cause it to stop working on a 64 bit machine? Wouldn’t upgrading it make it more rather than less likely to work on a newer machine?
Clues:
- We have another desktop app that went through a similar upgrade but experienced no problems on a 64 bit machine.
- The desktop app in question uses the default build configuration.
- The application references an older ActiveX component.
Helpful Facts:
- 64-bit machines support running applications as both 32-bit processes and 64-bit processes. The simplest way to find out if
![64bit_post1]( "64bit_post1")
an application is running as 32-bit is to look for the *32 suffix in task manager. When testing a pre-upgraded version of the app, the suffix was there. After the upgrade it wasn’t there. - 1.1 apps automatically run as 32-bit processes, but 2.0 apps can be run as either. On 64 bit machines, the OS looks at a flag in the PE header of the executable to determine which type of process it should run in. The flag is set by the compiler and can be ‘x86’, ‘x64’, or AnyCPU. AnyCPU means that it will run as a 32-bit process on 32-bit Windows and as a 64-bit process on 64-bit windows. The default configuration in Visual Studio is AnyCPU.
- A 64-bit process cannot load 32-bit dll’s – The application will crash with a BadImageFormatException.
an application is running as 32-bit is to look for the *32 suffix in task manager. When testing a pre-upgraded version of the app, the suffix was there. After the upgrade it wasn’t there.The Culprit: The problem was obviously the ActiveX Control, which was a 32-bit dll. It didn’t cause problems before the upgrade because the application was forced to load in a 32-bit process since it was using the 1.1 framework. Once it was upgraded, it started loading in a 64-bit process because of the ‘AnyCPU’ default configuration we were using.
Our Solution: We simply changed the build configuration to ‘x86’, which forces our app to run in a 32-bit process. I read where you can also make an out of process COM server that wraps the 32-bit dll, but that seemed like more work than we were willing to do at the time.
Anybody else have interesting 64-bit bug war stories or helpful hints?
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
