I'm a long time Cmder user and for idiosyncratic reasons I've historically run the 32-bit version of cmd.exe, so I didn't encounter this problem until just now.

I was building dotnet/wpf just now and noticed that it had trouble building correctly.

I debugged it down to these lines that fail to initialize the MSBuild property $(Architecture) correctly (it's initialized to 64 instead of x64), which in turn lead to my (dev) build failures in dotnet/wpf.

    <Architecture Condition="'$(Platform)'=='x64' or '$(Platform)'=='x86' or '$(Platform)'=='arm' or '$(Platform)'=='arm64'">$(Platform)</Architecture>
    <Architecture Condition="'$(Platform)'=='Win32'">x86</Architecture>
    <Architecture Condition="'$(Architecture)'==''">x64</Architecture>

Ultimately, this seems to the what caused my troubles, where %architecture% is (seemingly) set for script-local use, but the environment-variable ultimately leaks out of the script:

I have two suggestions:

• Use setlocal at the top of the batch file wherever it makes sense. I realize that the 'fix' may not be as simple as adding a one-line change, since some env-vars might be exported deliberately, whereas others might be leaking merely as a side-effect.
• Consider using (more) canonical names like x86, x64, arm, arm64 etc. for architecture (instead of 86, 64 etc. ).