Having an in-depth knowledge about your Windows version is critical for many tasks. As a seasoned IT pro and full-stack developer who utilizes PowerShell daily, I often need to check Windows versions for installing software, troubleshooting configuration issues, audits, documenting environments, and more.
In this comprehensive 3,000 word guide, we‘ll explore a set of intelligent approaches to detect your Windows build using PowerShell capabilities that both developers and IT administrators rely upon.
The PowerShell Toolkit for Finding Windows Version
Based on my decade of experience as a full-stack .NET developer and systems programmer leveraging PowerShell, these are the top tools to find Windows edition, build number, and key details:
Get-ComputerInfo – Simple cmdlet returning core properties
Get-ItemProperty – Read registry keys containing Windows metadata
systeminfo – See all configuration info including OS Version
[System.Environment] – Leverage .NET runtime for version details
Get-CimInstance – Query extensive OS properties from CIM/WMI
And here are some additional power user techniques:
- Check file properties on kernel DLLs
- Parse output of winver.exe utility
- PowerShell-based Win32 API calls
Now let‘s explore each approach hands-on with realistic usage examples and sample code as an experienced developer and systems engineer.
Method #1: Using Get-ComputerInfo
The Get-ComputerInfo cmdlet is a native PowerShell tool introduced in PS v3 to retrieve common system properties like OS, domain info, hardware resources, etc.
Here is example output:
PS> Get-ComputerInfo
WindowsProductName : Windows 11 Pro
OsHardwareAbstractionLayer : Version 2.0
UserDomainName : CORP
ComputerName : MyDesktop When I need to quickly check the high-level Windows version or edition, Get-ComputerInfo is one of the first tools I reach for in PowerShell.
It returns essential details about the OS without needing any imports or advanced code:
Get-ComputerInfo | Select WindowsProductName, WindowsVersion, OsHardwareAbstractionLayerOutput:
WindowsProductName : Windows 11 Pro
WindowsVersion : 2009
OsHardwareAbstractionLayer : Version 2.0The WindowsVersion property holds the vitally important Windows build number which pinpoints the exact OS patch level beyond the marketing names.
For my workstation example above running Windows 11, build 2009 corresponds to the 21H2 "November 2021 Update" release channel.
These granular build numbers identify unic updates and serve as prerequisites for certain software & configuration processes – that‘s why as a DevOps engineer I am constantly checking them in CI/CD pipelines and scripts.
An easy trick is to isolate the WindowsVersion with simple filtering:
Get-ComputerInfo | Select WindowsVersionNow as a full-stack developer, I leverage these core properties across projects for all kinds of automation tasks:
- Document system specs
- Feed CMDB platforms like ServiceNow
- Populate inventory databases
- Conditional logic based on OS
- Validate test matrices
And since Get-ComputerInfo wraps WMI interfaces as a high-level cmdlet, it runs speedy and light.
Next let‘s look at going directly to an authoritative source under the hood – the Windows registry.
Method #2: Query Windows Registry Keys
As an experienced infrastructure engineer, I know that vital low-level intelligence around Windows edition, version info, product IDs, etc are stored in registry hives on local or remote systems.
The registry holds clues that can help precisely identify Windows builds. And using PowerShell‘s Get-ItemProperty, we can directly access registry entries.
Here is the specific hive containing detailed OS descriptors:
HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersionThis CurrentVersion key reveals all kinds of metadata around Windows SKU type, registered org, build lab, etc.
Let‘s read the ReleaseID value which surfaces the numeric build label:
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").ReleaseIdOutput on my Windows 11 box:
2009And since Get-ItemProperty wraps the underlying Windows registry APIs, we efficiently query the local or remote registry hives for this metadata with PowerShell‘s object pipeline.
As a systems automation engineer, I can parse further registry locations like HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\ for additional descriptors from core OS components.
Querying central registry hives provides authoritative build details – let‘s check out another go-to tool next.
Method #3: Leverage systeminfo Utility
Among my essential admin tools as a platform engineer is the handy systeminfo CLI which has been built into Windows for decades.
It renders a complete report of all system properties ranging from BIOS, domain info, hotfixes, net config, OS version, and much more.
Here is a snippet showing the OS details:
C:\>systeminfo
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22000 N/A Build 22000
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
OS Build Type: Multiprocessor FreeAs a developer supporting enterprise infrastructure, systeminfo is a vital diagnostic tool I use to capture full system manifests – either directly or from PowerShell invocation.
The output can be consumed in so many ways:
- Saved to support tickets when troubleshooting
- Feed reporting dashboards
- Parse details into CMDBs
- Validate baseline OS builds
- Spot check inventory scans
And since no imports or learning is needed, new team members can easily run systeminfo for on-demand details.
Below I have charted the key Windows releases and their internal build numbers which are commonly seen in systeminfo reporting:
| Windows Version | Build Number | Release Date |
|---|---|---|
| Windows 11 (initial) | 22000 | Oct 2021 |
| Windows 10 2004 | 19041 | May 2020 |
| Windows 10 1909 | 18363 | Nov 2019 |
| Windows 10 1903 | 18362 | May 2019 |
| Windows 10 1809 | 17763 | Oct 2018 |
As you can see the build integers increment with each major Windows release providing clues around OS generation.
Next up, we‘ll tap into the richness of .NET classes from PowerShell to uncover OS version.
Method #4: Use .NET System.Environment Class
A prime advantage of PowerShell is deep integration with .NET Framework enabling us to leverage its thousands of classes from cmdlets/scripts.
This interoperability unlocks advanced functionality like invoking Windows APIs otherwise needing compilation or DLL imports.
As a full-stack engineer on products spanning UI frontends to lower-level systems code in C++/Rust, I utilize .NET libraries extensively in PowerShell automation.
And checking Windows builds is no exception…
Enter the System.Environment class containing broad methods to fetch OS, user, and process environmental data at runtime.
We can access this .NET class directly from PowerShell to reveal Windows-specific attributes without any declaration statements:
[System.Environment]::OSVersionOutput:
Platform ServicePack Version VersionString
-------- ----------- ------- -------------
Win32NT 6.3.9600.0 Windows NT 6.3.9600.0The Version property surfaces the core OS major.minor.build similar to the GetComputerInfo cmdlet.
And VersionString prints the full Windows branded string – great for conditional testing in scripts.
Isolating the version integer is simple by calling it directly:
[System.Environment]::OSVersion.VersionTherefore through .NET interop, PowerShell hands us OS metadata without needing COM or API invocation.
As a C# developer heavily using System namespaces, this carries over to streamlined scripting avoiding layers of complexity.
However if you do want to tap straight into Win32/COM APIs from PowerShell, that brings us to our last approach…
Method #5: Leverage CIM and WMI Interfaces
For our final technique, we will utilize CIM/WMI classes representing low-level Windows constructs like running processes, logon sessions, disks, services, OS entity, etc. which contain extremely detailed attributes.
And with Get-CimInstance in PowerShell, querying WMI becomes seamless without any coding compared to older VBScript days!
Specifically, we will target the Win32_OperatingSystem WMI provider class mapped to the currently running OS instance as the singular source of truth:
Get-CimInstance Win32_OperatingSystemThis surfaces TONS of metadata around Windows behaviors and configurations in one object:
BuildNumber : 18362
BuildType : Multiprocessor Free
Caption : Microsoft Windows 10 Pro
CodeSet : 1252
CountryCode : 1
CreationClassName : Win32_OperatingSystem
CSCreationClassName : Win32_ComputerSystem
CSName : MyPC
CurrentTimeZone : 60
EncryptionLevel : 256
FreePhysicalMemory : 16699
InstallDate : 20181105171914.000000+60
LastBootUpTime : 20190319090431.494026+60 Imagine the possibilities with dozens of properties around security policies, disk volumes, network params, registered org, plus the version build number.
As a systems programmer building cloud-scale distributed apps, I take full advantage of Get-CimInstance to monitor fleets of Windows nodes posting this telemetry to my time-series database for analysis.
If I need ONLY the OS caption showing edition, pipe to Select-Object:
(Get-CimInstance Win32_OperatingSystem).CaptionThis returns the familiar string like below WITHOUT needing WMI coding:
Microsoft Windows 10 ProThrough this WMI class, we unlock access to powerful Win32 API calls regarding OS state.
And Get-CimInstance becomes that middleware to easily consume it in PowerShell scripts.
Additional Power-User Techniques
Beyond the primary methods highlighted above to get Windows versions in PowerShell, here are some additional power user techniques I employ for special situations:
Check File Properties on Kernel Binaries
Low-level DLLs containing key OS components like kernel32.dll, ntoskrnl.exe, etc. reveal build strings in their file properties:
(Get-Item C:\Windows\System32\ntoskrnl.exe).VersionInfoParse Output of winver.exe
For a quick GUI window showing details, the good old winver.exe displays OS name, version, and supplemental hotfix notice:
C:\>(winver) 2> $null
# Parse output for detailsInvoke Win32 APIs
Finally, for ultimate control I can directly invoke platform invoke APIs from within PowerShell to query extremely granular OS descriptors like security masks, group policy state, handle metrics, and special build flavors:
$Signature = @‘
[DllImport("kernel32.dll")]
public static extern int GetVersion();
‘@
$OsVersion = Add-Type -MemberDefinition $Signature -Name ‘PInvoke‘ -Namespace ‘Win32‘ -PassThru
[Win32.PInvoke]::GetVersion() # Returns Windows build numberThis allows me to flex the full power of Windowsnative APIs armed with PowerShell convenience.
Summary
In closing, as an experienced infrastructure engineer, gaining insights into your Windows version serves countless purposes from documenting new deployments to conducting security analysis.
Throughout this guide, we explored over 5 methods spanning .NET classes, command-line utilities, WMI/CIM providers, registry keys, and DLL file properties to reliably obtain granular OS build specifics all from PowerShell:
- Get-ComputerInfo – Simple properties from native cmdlet
- Get-ItemProperty – Direct registry access to metadata
- Query systeminfo – Complete OS report
- [System.Environment] – .NET class for version attributes
- Call Get-CimInstance – Interact with powerful WMI providers
And I outlined several advanced power-user techniques like consuming Win32 APIs for ultimate control.
As you gain experience with PowerShell, take advantage of these tools to unlock precise OS details critical for your administration, development, and automation tasks.
I hope this guide serves you well on your infrastructure journey!