EDR-7621 - Source the OS block from WMI instead of frozen registry values - #3
Open
Schogol wants to merge 1 commit into
Open
EDR-7621 - Source the OS block from WMI instead of frozen registry values#3Schogol wants to merge 1 commit into
Schogol wants to merge 1 commit into
Conversation
The OS fields were read from HKLM\...\CurrentVersion registry values, two of which Windows freezes and never updates: ProductName stays "Windows 10 ..." and CurrentVersion stays "6.3" on Windows 10/11. So NAME was reported as "Windows 10 Pro" and KERNEL_VERSION as "6.3" on Windows 11. Query Win32_OperatingSystem once (Caption, Version, BuildNumber) and feed NAME, MAJOR/MINOR/BUILD and KERNEL_VERSION from it; NAME strips the leading "Microsoft " to keep the prior format. The result is cached in a single query, and each field falls back to its registry value when WMI is unavailable.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Disclaimer: This fix was created using Claude
The Issue
The {OS} block in pdmdata.txt reports stale values on Windows 11. On a Windows 11 machine (build 26200):
{OS}
TYPE : Windows
NAME : Windows 10 Pro <- should be "Windows 11 Pro"
BITNESS : x64
MAJOR_VERSION : 10
MINOR_VERSION : 0
BUILD_NUMBER : 26200
KERNEL_VERSION : 6.3 <- should be "10.0"
Two fields are wrong: NAME reads "Windows 10 Pro", and KERNEL_VERSION reads "6.3".
The Cause
Both fields were read directly from legacy values under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion that Windows does not update on Windows 11:
NAME came from ProductName, which reads "Windows 10 ..." on Windows 11 (both fresh installs and upgrades).
KERNEL_VERSION came from CurrentVersion, which reads "6.3" - the value has not changed since Windows 8.1.
Neither reflects the true current OS. MAJOR_VERSION/MINOR_VERSION (10/0) are correct but do not distinguish Windows 10 from 11 (both are NT 10.0); the reliable discriminators are the build number (CurrentBuild >= 22000 = Windows 11) and WMI. The same values flow into every consumer: the gatherer builds the OS block from these getters, and pdm-proto-wrapper forwards them into its protobuf (os.name / version fields) for the launcher.
The Fix
Source the OS block from a single, cached Win32_OperatingSystem WMI query (Caption, Version, BuildNumber) and feed NAME, MAJOR/MINOR/BUILD, and KERNEL_VERSION from it; strip the leading "Microsoft " from Caption to keep the prior NAME format. Each field falls back to its registry value if WMI is unavailable. WMI reports the true current OS, so NAME becomes "Windows 11 Pro" and KERNEL_VERSION "10.0". Win32/registry paths are kept for all other data (WMI is only used where the registry value is wrong).Verification (Windows 11, build 26200)
The full pdm library + pdmCLI build succeeds; the rebuilt pdmCLI emits NAME = Windows 11 Pro, KERNEL_VERSION = 10.0, MAJOR/MINOR/BUILD = 10/0/26200.
The module's gtest suite passes 7/7, including Unicode.DataIsValidUTF8, which validates the emitted OS strings.