.NET Compilation for 64-bit Platform Support

At work, I was faced with a problem of a .NET program looking at the wrong registry values, and picking up the wrong machine.config. You see, a 32-bit application running on 64-bit Windows is supposed to be presented with its own 32-bit view of the machine, from registry entries to system DLLs. This is all pretty spectacular, which is why they call it WOW. For more information on WOW64, Wikipedia is your friend.

.NET is a bit tricky, though. By default, .NET applications are compiled with the /platform:anyCPU [MSDN /platform documentation]. This means they will run as 32-bit applications on 32-bit systems, and as 64-bit applications on 64-bit systems. When a .NET application is part of a larger system of applications, this can cause incompatibilities. All the regular C-compiled executables will run in 32-bit, but your .NET app will be interacting with the 64-bit environment and be out of sync.

To solve this, you can simply specify /platform:x86 when part of a 32-bit package, and /platform:x64 when part of a 64-bit package.


The next question is: How do I know if a .NET program was compiled with the /platform option specified as x86, x64, or anyCPU?

For regular applications, a Google search yielded the following blog post on using dumpbin to determine if it is a 32-bit or 64-bit application. For .NET applications, using dumpbin /HEADERS isn't quite enough. Programs compiled with the anyCPU option will still show up as:
14C machine (x86)
32 bit word machine

Dumpbin has other options, though, and /CLRHEADER comes to the rescue. For anyCPU applications, the relevant portion is:
1 flags
IL Only
x86 applications get:
B flags
IL Only
32-Bit Required

Dumpbin is a highly useful diagnostic tool, as I find out often.

Update: I just tried dumpbin on an /platform:x86 application running on 32-bit Windows, and the "flags" attribute had no lines beneath it, but it looks like the "1" vs "B" is still accurate. Perhaps this expansion is new in Visual Studio 2008's dumpbin.

File Server Aggravation

I left my server up over the weekend. It was booted into Windows. It was frozen this morning. This is quite annoying, but does have one positive piece. Basically, it is unlikely to be software-related at this point. Since the computer freezes when using either or both sticks of RAM, I'm betting it's not the RAM. The chances of both sticks having slight errors at the same time seems small. I'm going to swap out a different PCI express graphics card and see if that helps things. If it doesn't, I'll be pretty much out of ideas, and almost certainly out of cheaply tested ideas.

I'm house-sitting for my parents, though, so I won't have a whole lot of opportunity to test things, anyway. Damned inconvenient, really.