> So before the change, the 16299 SDK wasn't being detected either, but perhaps the 10240 one was?

So I'm just confused....

It does seems likely that 10240 of the UCRT was being used (based on the attached msbuild logs).  Howevr, the UCRT warning in the build process was fine, and said I was using 16299 (see https://buildbot.python.org/all/#/builders/31/builds/717/steps/1/logs/stdio for the last working build on Win10).  

I'm not sure what to trust - the msbuild log or whatever the ucrtused test is doing for detection?

In either case, this issue commmit does seem to force selection of the non-existent 15063 SDK, at least based on msbuild.log - the process doesn't get far enough to run the UCRT version check.

Using Win10 for the moment, under "Program Files (x86)" I do seem to have some older UCRT SDKs (in "Microsoft SDKs/Windows Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug") as 10.0.10150.0, 10.0.10240.0 and 10.0.16299.0.  Whereas only 10.0.16299.0 exists in the "Windows Kits/10/Platforms/UAP" directory.

So I guess msbuild is not strictly picking the "earliest" for UCRT as 10240 isn't quite the earliest.

In comparison, my Windows 7 worker also has the 15063 UCRT SDK so the enforced minimum works there for the UCRT path.  Of course, the ucrtused test in the build process seems to always say 16299.

I ran the requested msbuild command on the Win10 worker as part of PCBuild\build.bat just after the first find_msbuild.bat call.  I'm attaching the log files as msbuild-win10-good.log (commit prior to this change) and msbuild-win10-bad.log (after this change).

So I guess the question is exactly what do we need to enforce in the build process and/or provide at a minimum on a worker?  Should I just install the older 15063 SDK on Win8/10, or should we include some more recent versions in the build time version check?  What is a new user trying to build Python likely to have (assuming they're still using VS2015).