Repository navigation
Windows version from sys.getwindowsversion() is wrong in binaries that do not declare Windows 10 support #146299
Description
Activity
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Mar 22, 2026 but it is an issue for apps that embed CPython and do not have a PE manifest, or do not declare Windows 10 support.
Isn't it their fault then? cc @zooba should we support this (weird) setup?
- addedtype-featureA feature request or enhancementA feature request or enhancementinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
on Mar 22, 2026 should we support this (weird) setup?
See the comment in the linked function, the current implementation explicitly tries to support apps running in compatibility mode. If CPython doesn't want to support running in compatibility mode, you could just call
GetVersionExand spare yourself the trouble. :)Also note that the compatibility mode is on by default, you have to explicitly add a PE manifest to your binary with the right config to opt-out of it, so I expect it to be fairly common among binaries that embed CPython.
Oh I see. Ok so the fix seems fairly simple then!
- removedtype-featureA feature request or enhancementA feature request or enhancementpendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
on Mar 22, 2026 has an internal compatibility shim where if the calling binary does not declare support for Windows 10, it will shim the actual DLL versions with a fake Windows 8 version for system libraries
Hahahaha, they got us good! We added this code path when this shim didn't exist, apparently.
I think we should go back to
GetVersionExand document it as respecting OS compatibility settings.platformshould read the version using WMI, which will be accurate for reporting.Reporting the compatibility version is the correct behaviour here:
we should go back to
GetVersionExand document it as respecting OS compatibility settings.platformshould read the version using WMI, which will be accurate for reporting.Keeping this issue open until we completely remove
_sys_getwindowsversion_from_kernel32and rely on the reported version number fromGetVersionExfor all paths throughgetwindowsversion.
Bug report
Bug description:
Repro:
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>line from the PE manifest, or just delete the whole manifest from the binary. Write back the patched binary. This enables compatibility shims for Windows 8 in the Win32 API when running the binary....\python.exe -c "import sys; print(sys.getwindowsversion())"The root cause is very similar to https://issues.chromium.org/issues/494938698, see the full description there.
To retrieve the Windows version, Python reads the file version from
kernel32.dll, becauseGetVersionExwill report old values due to backwards compatibility. However,GetFileVersionInfoW, which is used in thesysmodule.cimplementation ofsys.getwindowsversion()also has an internal compatibility shim where if the calling binary does not declare support for Windows 10, it will shim the actual DLL versions with a fake Windows 8 version for system libraries, resulting insys.getwindowsversion()reporting a wrong OS version.This is not an issue for python.exe directly, because it has a proper PE manifest that declares Windows 10 support, but it is an issue for apps that embed CPython and do not have a PE manifest, or do not declare Windows 10 support.
Proposed fix
Replace the whole implementation with a call to
RtlGetVersionfrom ntdll, which is now officially documented, returns the correct version without shims and there's a substantial list of prominent projects relying on it already.CPython versions tested on:
3.15
Operating systems tested on:
Windows