Hello guys and gals!

In this article, we’re going to tackle a pretty frustrating scenario: making sure all your .NET assemblies or even native DLLs target the same architecture. At the time of writing, applications tend to be targeted at x86 or x64 architectures, or both. However, mixing DLLs or executables compiled for different architectures is a recipe for disaster. This kind of disaster, in fact:

That’s a BadImageFormatException, saying:

An unhandled exception of type ‘System.BadImageFormatException‘ occurred in Microsoft.VisualStudio.HostingProcess.Utilities.dll
Additional information: Could not load file or assembly ‘ClassLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. An attempt was made to load a program with an incorrect format.

This is why it’s happening:

That’s a very, very stupid thing to do, having an x64 console application depend on an x86 class library (or DLL). Remember:

Great, now you know. But you’re bound to run into the BadImageFormatException problem anyway, because while it’s easy to control the bitness of the assemblies in your project, you often depend on DLLs provided by third parties, and their own bitness isn’t clearly defined. Unfortunately, you can’t rely on rightclick -> Properties -> Details because that doesn’t give you the bitness at all.

Fortunately, however, there are tools you can use to find out what architecture those DLLs are compiled for.

Let’s start off with .NET assemblies. If the DLL in question is a .NET assembly, you can use the corflags utility to find out the bitness. corflags is part of the Visual Studio developer tools, so you’ll first need to start a Visual Studio developer command prompt (see this StackOverflow thread or search Windows for CorFlags.exe in case you can’t find one from the Start menu).

Once you’ve located CorFlags.exe or have a Visual Studio developer command prompt, runCorFlags.exe with the full path to the DLL you want to inspect, and check the 32BIT setting in the output:

Now CorFlags.exe works great to find out the architecture of a .NET assembly, but can’t tell you the architecture of a native DLL. This is what happens if you try to use it with SDL2.dll, for instance:

For unmanaged/native DLLs, we can instead use dumpbin. This will spit out a bunch of information, so you can find the architecture quickly if you filter the information by including only the line containing the word “machine”, as the linked Stack Overflow answer suggests:

So there you go – this article has presented two different ways to check the bitness or CPU architecture of managed and unmanaged DLLs respectively, which helps when troubleshooting those dreaded BadImageFormatExceptions. In reality this article is a consolidation of the information in the two Stack Overflow threads linked above, and I would like to thank the authors because I have found their tips useful on many occasions.

This article was originally posted here at Programmer’s Ranch on 28th September 2014.