Skip to content

Windows version from sys.getwindowsversion() is wrong in binaries that do not declare Windows 10 support #146299

Description

@MatejKafka

Bug report

Bug description:

Repro:

  1. Install Python for Windows (ideally create a new installation, since you'll need to patch it).
  2. Using Resource Hacker, or any other PE resource editing tool, remove the <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.
  3. Run ...\python.exe -c "import sys; print(sys.getwindowsversion())"
  4. Observe that the returned version indicates Windows 8 (major=6, minor=3) instead of the actual OS version (major=10, minor=0 for both Windows 10 and 11).

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, because GetVersionEx will report old values due to backwards compatibility. However, GetFileVersionInfoW, which is used in the sysmodule.c implementation of sys.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 in sys.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 RtlGetVersion from 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

Activity

  1. picnixz commented on Mar 22, 2026

    @picnixz
    Member

    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?

  2. added
    type-featureA feature request or enhancement
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    pendingThe issue will be closed if no feedback is provided
    on Mar 22, 2026
  3. MatejKafka commented on Mar 22, 2026

    @MatejKafka
    Author

    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 GetVersionEx and 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.

  4. picnixz commented on Mar 22, 2026

    @picnixz
    Member

    Oh I see. Ok so the fix seems fairly simple then!

  5. removed
    type-featureA feature request or enhancement
    pendingThe issue will be closed if no feedback is provided
    on Mar 22, 2026
  6. zooba commented on Mar 23, 2026

    @zooba
    Member

    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 GetVersionEx and document it as respecting OS compatibility settings. platform should read the version using WMI, which will be accurate for reporting.

  7. thexai commented on Jul 23, 2026

    @thexai
    Contributor

    @zooba

    PR to allow build for UWP (#152604) also fixes this.

  8. zooba commented on Jul 23, 2026

    @zooba
    Member

    Reporting the compatibility version is the correct behaviour here:

    we should go back to GetVersionEx and document it as respecting OS compatibility settings. platform should read the version using WMI, which will be accurate for reporting.

  9. zooba commented on Aug 18, 2026

    @zooba
    Member

    Keeping this issue open until we completely remove _sys_getwindowsversion_from_kernel32 and rely on the reported version number from GetVersionEx for all paths through getwindowsversion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    OS-windowsinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions