I believe I've identified the issue, and put a workaround in place.

The 986b7ffc commit somehow affected which binary of mt.exe is being run (for version 5.2.3790.2076, 2005), changing from:
  C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64\mt.exe
to
  C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe
The 32-bit version is what is crashing, at least when trying to add the manifest to a 64-bit library (it does work for other manifest operations).

I thought the binary was just incompatible, but I located a later version of mt (6.3.9600.17336, 2012) under C:\Program Files (x86)\Windows Kits\8.1 for which both the 32-bit and 64-bit versions worked.  Of course, there was also the issue of why Win8 was working with the 5.2 32-bit version.

Then I noticed a .NET config file for the newer 6.3 mt to handle running on systems with .NET 4 but not 1.1 or 2.  As it turns out, the Win10 buildbot is .NET 4+ only, while the older 8.1 buildbot has frameworks back to .NET 2.  So that's probably what kept the Win8 buildbot from failing just like Win10.

What I did for now is borrow the .NET exe config files from mt 6.3 for use with the SDK mt 5.2 binaries, which looks like it's done the trick.


It might be best to restore the old behavior if possible so building works without the workaround, but I'm not sure how the binary is being determined.  None of the mt binaries are in the default path so must be found by the build process somehow.  Reverting to using env.bat with the latest source (so msbuild is found on the path) still ends up calling the 32-bit mt.  So something else in the changes must be influencing the binary choice.  And given that this only affects using the scripts to build 2.7 on a recently installed machine, hard to say if it's worth much effort.