I got back into my office after a few days off and had an email to install a new monitoring tool. I only needed to run a batch file to install it, then it would monitor OneNote, make its reports and keep itself updated.

I clicked the link in the batch file and the a DOS window popped open, then disappeared. Then the tool crashed. I tried again (to see if this was a deterministic crash) and it crashed again. A quick look at the batch file with the author of it showed this:

echo Detecting OS processor type


echo 32-bit OS

xcopy "\\servername\folder\tool\x86\tool.exe" "C:\localfolder\" /y



echo 64-bit OS

xcopy "\\servername\folder\tool\x64\tool.exe" "C:\localfolder\" /y


Looks good. If I have a 64 bit machine (which I do), the x64 version gets installed, and x86 users will get the x86 version.

A little investigation showed that (confusingly) the x86 version was being installed.

So I started thinking about how this would happen. I opened a command prompt and typed SET to see if Processor_Architecture was AMD64, and it was.

A little more thought about this made me remember that I have a Click to Run install of Office. And it just so happens that Click to Run is a 32 bit install of Office, so the minimal virtual machine in which it runs is also, by necessity, 32 bit. My assumption was that since I was running the batch file from Outlook, I was running in a 32 bit environment. A quick test of copying the link from email and running it from Windows properly installed the 64 bit version of the tool.

Interesting that the environment variable was the culprit. A bit more poking around showed that the environment variable PROCESSOR_ARCHITEW6432 is what we should be using in virtual environments like this, so the tool was quickly updated:

echo Detecting OS processor type


if "%PROCESSOR_ARCHITEW6432%"=="AMD64" goto 64BIT

And so on…

Now the batch file installs the correct version of the tool based on the base OS.

Questions, comments, concerns and criticisms always welcome,