Python 3.11.5 to 3.11.6 upgrade fails: vcruntime140.dll not found

[dconnet]

Bug report

Bug description:

While updating 3.11.5 to 3.11.6 using python-3.11.6-amd64.exe, installation fails multiple time while precompiling. This is on a fairly clean up-to-date Win10 system with no Visual Studio. On a system with Visual Studio, the upgrade works.

CPython versions tested on:

3.11

Operating systems tested on:

Windows

Linked PRs

• gh-110437: Allow overriding VCRuntimeDLL with a semicolon separated list of DLLs to bundle #110470
• [3.12] gh-110437: Allow overriding VCRuntimeDLL with a semicolon separated list of DLLs to bundle (GH-110470) #110555
• [3.11] gh-110437: Allow overriding VCRuntimeDLL with a semicolon separated list of DLLs to bundle (GH-110470) #110556

[zooba]

You should have a set of log files in your %TEMP% directory. Could you zip them up and attach them to this issue?

[dconnet]

These are all the logs (started the upgrade with a clean temp)

InstallLogs.zip

[dconnet]

I did forget to note: downloading vc_redist.x64.exe from MS and installing that resolves the issue. (This also affected Windows11 - I have a couple VMs for testing)

[zooba]

Hmm, it seems like somehow we ended up with an earlier version of vcruntime140.dll in the 3.11.6 release than was in the 3.11.5.

Usually this shouldn't matter, because it's the key file and the latest version should be kept, but for some reason it was removed but not reinstalled here.

I haven't got time right now to dig any further, but I'll try and look closer at it tomorrow. Out of interest, if you uninstall 3.11.5 and then install 3.11.6 (i.e. don't do an upgrade), does it install the file?

[dconnet]

Another note: Out of curiosity, I tried the 3.12 installer - that worked.

[dconnet]

Actually, I had to uninstall 3.11.6 since the install worked - the precompile failure didn't rollback the install.
After uninstalling that and reinstalling, it did work.

[zooba]

Looks like repairing 3.11.6 will add the file back, but it definitely gets lost in the upgrade process for some reason.

[zooba]

This blog covers the reasons: https://learn.microsoft.com/en-us/archive/blogs/astebner/why-windows-installer-removes-files-during-a-major-upgrade-if-they-go-backwards-in-version-numbers

It seems that the image used for 3.11.6 replaced toolset v14.36 with v14.37, but our build used v14.35 instead. The image for 3.11.5 had both v14.35 and v14.36, but the build chose the latter. It's always supposed to choose the latest, but apparently it didn't in this case. Most likely an issue on the image.

I think the best option is going to be to manually manage the redistributable files rather than picking them up from the build machine. Now that our build machines are subject to the whims of cloud CI, we clearly can't assume we won't go backwards in version.