PROCESSOR_ARCHITECTURE returns AMD64 in some 32-bit processes

I ran into a bizarre scenario where a 32 bit process claims that its PROCESSOR_ARCHITECTURE is AMD64, causing failure in components that make decisions based on that flag.

I isolated it to these steps:

  • In VS2010, Create a Library project
  • In the Project properties / Debug tab, set Start External Program to the VS exe (e.g. C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEdevenv.exe)
  • Do Ctrl-F5 to run, which launched another VS instance
  • In this second instance, create a Console app and paste the following code

In Main:

Console.WriteLine(Environment.GetEnvironmentVariable("PROCESSOR_ARCHITECTURE"));
Console.ReadLine();
  • Now run the Console app

And it displays AMD64, even though it’s a 32 bit process (the default for Console apps, per Build settings).

Question: can others repro this as well, and if so can you explain it?

Note: if you’re curious, the reason I run VS this way is that I’m using an experimental hive for the second instance

UPDATE: note that in my real scenario, I’m not looking up this environment variable myself. Instead, I use a component (SQLCE) which looks it up and relies on it being correct.

Answer

Based on my findings, I think I can come up with a reasonable explanation for this.

By having a project set to target “Any CPU” (the default for class libraries), the PROCESSOR_ARCHITECTURE environment variable will be set to what’s most capable when running the external process, “AMD64” for a 64-bit OS. However since the Visual Studio IDE is actually a 32-bit process running with WOW, this can be confusing to processes started from within the second instance.

Forcing the library to target the 32-bit platform explicitly will set things correctly I’ve found. Perhaps you should do that.

Leave a Reply

Your email address will not be published. Required fields are marked *