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
- 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.
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.