Debug game report shows wrong OS version on Windows

[xuvatilavv]

Describe the bug

The game report claims I'm running Windows 10.0 version 2009 when I'm currently on Windows 10 version 21H2.

I've also noticed here on GitHub there are only 6 total issues reporting version 21H1, and none with version 21H2, which is rather suspicious. Seems like a lot of current issues may have the wrong version included.

Sorry if there's already an existing issue on this, it's a little hard to search for since the game report is present in every issue.

Steps to reproduce

1. In CDDA, load any character in any world.
2. Generate a game report from the debug menu. (Main menu > Debug Menu > Info > Generate game report)
3. Paste the report somewhere for reference.
4. In Windows Settings, go to System > About.
5. Observe that the OS version from the game report is different from the version reported in Windows Settings.

Expected behavior

The game report and the OS should show the same OS version.

Screenshots

No response

Versions and configuration

• OS: Windows
  • OS Version: 10.0 2009
• Game Version: 1ed949a [64-bit]
• Graphics Version: Tiles
• Game Language: System language []
• Mods loaded: [
  Dark Days Ahead [dda],
  Disable NPC Needs [no_npc_food],
  No Fungal Growth [no_fungal_growth],
  Bionic Professions [package_bionic_professions],
  Blaze Industries [blazeindustries],
  Magiclysm [magiclysm],
  Generic Guns [generic_guns],
  DinoMod [DinoMod],
  Alternative Map Key [alt_map_key],
  Crazy Cataclysm [crazy_cataclysm],
  Stats Through Kills [stats_through_kills]
  ]

Additional context

System info as reported in Windows Settings:
Edition Windows 10 Home
Version 21H2
Installed on ‎26 ‎Nov ‎2021
OS build 19044.1526
Experience Windows Feature Experience Pack 120.2212.4170.0

[xuvatilavv]

Left this issue open because a similar problem exists in Windows 11 due to it using legacy values in the registry for most version information.

I'm going to implement option A shortly as I expect it's "good enough for now" but am documenting a few other options here in case someone else wants to implement a more proper one, Microsoft deprecates more keys, someone's searching for a solution for a different project, for the benefit of future generations, etc.

---

The problem

It appears that these registry values are present in Windows 11 and will not be updated:

# Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

CurrentMajorVersion = 10
CurrentMinorVersion = 0
ReleaseId = 2009
ProductName = Windows 10 Home  # Or Pro, Enterprise, etc as appropriate

As far as I can tell DisplayVersion will continue to update, using the same format as Win10. This results in the reported version for Win10 and Win11 being identical with the current code.

Sources

(such as they are, I mostly only found it discussed it in the MS forums)
1, 2, 3

Potential solutions

Note: Existing comments state that most Windows APIs will lie about the OS version if an app doesn't have a compatibility manifest. That would need to be investigated for the other APIs mentioned here.

A) Read build number from registry

The only confirmed registry values that will indicate Win11 are build numbers, with values >= 22000 being Windows 11 ("at least for now", according to source #1 above). On my machine (Windows 10 21H2) those values are stored as:

# Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

CurrentBuild = 19044   # apparently various Windows releases have junk data for this one
CurrentBuildNumber = 19044
UBR = 0x5f6   # Stands for "Update Build Revision"

We could live with the literal reported version for Win11 (e.g. Version 10.0 Build 22000.100, somewhat confusing), or check the build number and report Windows 11 when appropriate.

Pros:

• Trivial to add
• Minimal testing required

Cons:

• Remains undocumented as far as I can tell
• Microsoft may decide to break it again

B) Call AnalyticsInfo.GetSystemPropertiesAsync() from the WinRT API

Pros:

• Documented
• Works for all Win10 and Win11 releases

Cons

• Requires adding C++/WinRT as a dependency
• Values may not be stable

C) Call to winbrand.dll (see StackOverflow)

Pros:

• Seems fairly straightforward

Cons:

• Private API
• Undocumented
• Interface/Values may not be stable
• Not sure if it exists on older releases

D) Query WMI and read Caption from Win32_OperatingSystem

Pros:

• Documented
• Stable
• Works at least as far back as Windows XP?

Cons:

• Requires managing COM ports and such, sounds complicated

[LeahLuong]

The attitude around this git is fairly laissez-faire; your implementation of this feature is likely to be the permanent 1, @ least until it breaks again. I'd recommend making it as robust as you can. I think you already understand version reporting is mainly there for troubleshooting. What's the worst that could happen??