You can tell which version of Windows you have in under ten seconds: press Windows key + R, type winver, and press Enter. A small dialog box opens showing your Windows edition (Home, Pro, Enterprise) and version number (such as 24H2), plus the OS build. For architecture and full build details, open Settings > System > About.
That is the whole answer. What follows explains why Microsoft splits "version" into four different numbers, why the four disagree with each other in ways that genuinely matter, and how to read each one correctly.
What "version" actually means inside Windows
Microsoft overloads the word "version" across four distinct identifiers that update on different schedules. The product name (Windows 11) changes roughly every three to six years. The release version (24H2, 23H2) changes annually and is what Microsoft's lifecycle pages track. The OS build number changes with each monthly cumulative update and is the number that actually determines your patch state. The edition (Home, Pro, Enterprise, Education, IoT Enterprise, LTSC) determines which features exist at all. A fifth layer, the processor architecture (x64, ARM64, x86), determines which installers will even run.
The mechanism behind this layering is Windows servicing. Microsoft ships a single build per release and differentiates editions and features at runtime through licensing packages and feature packages. That is why two machines on "Windows 11 24H2, build 26100" can behave differently: one holds a Pro license and the other Home, and the Pro machine accepts Group Policy and BitLocker configuration the Home machine rejects. The winver dialog shows the release and build together because those two numbers jointly define your servicing baseline. Settings > System > About shows the same data plus edition, architecture, and install date. System Information (msinfo32) adds the UEFI/Secure Boot state and BIOS mode.
The Registry stores the authoritative values under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion: ProductName, DisplayVersion, CurrentBuild, UBR (the revision suffix of the build), and EditionID. The UBR is the counterintuitive detail most guides miss. Build 26100.2314 means base build 26100 with update revision 2314 applied. If you cite only "26100" when reporting a problem, a support engineer cannot tell whether you have the latest monthly patch.
The numbers that define your servicing baseline
Build numbers cluster into recognizable ranges. Windows 10 spans 10240 (1507) through 19045 (22H2). Windows 11 began at 22000 (21H2), moved to 22621/22631 (22H2/23H2), then 26100 (24H2). Windows 11 25H2 continues the 26200 range. Each monthly Patch Tuesday update increments the UBR by a few hundred; a gap of more than roughly 60 days between your UBR and Microsoft's current release usually means a missed cumulative update or a paused Windows Update.
Release cadence matters for the "do I need to upgrade" question. Windows 10 reached end of support on October 14, 2025. Consumer editions after that date receive no security updates unless enrolled in the consumer Extended Security Updates program, which Microsoft priced at USD 30 for one year of coverage. Windows 11 Home and Pro releases receive 24 months of servicing from release; Enterprise and Education receive 36 months. A 23H2 Home machine therefore fell out of support well before a 23H2 Enterprise machine did, which is one reason two machines showing identical version strings can have very different risk profiles.
The table below reconciles the identifiers against each other.
| Identifier | Where it appears | Example | Changes when |
|---|---|---|---|
| Product name | winver, Settings | Windows 11 | Major release cycle (years) |
| Release version | winver, Settings | 24H2 | Annual feature update |
| OS build (base) | winver, msinfo32 | 26100 | Feature update |
| UBR (revision) | winver, Settings | .2314 | Monthly cumulative update |
| Edition | Settings > About | Pro | License or reinstall |
| Architecture | Settings > About | x64 | Never, absent reinstall |
Read the rows bottom-up when troubleshooting: architecture blocks installers, edition blocks features, UBR blocks patching, release blocks lifecycle, and product name is mostly marketing.
Where the quick methods break down
Every method has a failure mode. Microsoft removed the winver Start menu search shortcut in Windows 11, so typing "winver" into search may surface nothing useful; the Run dialog (Windows key + R) still works. On domain-joined machines, Group Policy can hide Settings pages, leaving msinfo32 or the Registry as the reliable path. On Windows Server, winver reports the release but the Admin Center shows a different product name, and Server Core has no Settings app at all.
Virtual machines and cloud instances add a layer. A Windows 11 VM running under Hyper-V reports its guest build accurately, but the "System type" line shows "x64-based PC" regardless of whether the host is ARM, because the guest sees an emulated x64 platform. Windows on ARM hardware (Snapdragon X, older SQ-series) reports "ARM64-based PC" and runs x64 software through emulation, which is why some installers fail even on a fully patched machine.
Long-Term Servicing Channel (LTSC) builds are the professional caveat worth flagging. An LTSC 2021 machine reports Windows 10, build 19044, and may sit years behind the current UBR by design. Tools that flag "outdated build" will misclassify it. Conversely, Insider builds carry a build number in the 26000+ range with a .1xxx suffix pattern and a watermark on the desktop; do not treat an Insider build as production.
Red-flag warning bullets:
A build number lower than the current Patch Tuesday release by more than two months suggests paused updates or a failed cumulative install. An edition of "Windows 10 S" or "Windows 11 Home in S mode" blocks non-Store installers entirely; verify before blaming the app. A ProductName of "Windows 10" with a build above 22000 means a registry inconsistency or a tampered install; verify with msinfo32. A missing UBR or a build ending in .0 indicates a fresh feature-update install that has not yet received its first cumulative patch. A 32-bit (x86) install on hardware that supports x64 caps you at 4 GB of usable RAM; check "System type" before adding memory.
Common misconceptions about Windows versions
The most persistent misconception is that the product name tells you the patch level. It does not. "Windows 11" has described builds from 22000 to 26200 and will describe future ones; the name is a family label, not a servicing state. A second misconception treats the release version as the build. They correlate but diverge: 23H2 shipped on both 22631 and, for some SKUs, 22621 with an enablement package, so two 23H2 machines can report different base builds.
A third error equates edition with capability. Home and Pro share the same kernel, drivers, and patch stream; Pro adds BitLocker, Hyper-V, Remote Desktop host, Group Policy, and domain join. An app that fails on Home will usually fail identically on Pro for the same build, so edition is rarely the root cause of a software fault. A fourth error assumes ARM64 is incompatible with everything; x64 emulation on Windows 11 ARM is mature, and the failure rate is concentrated in kernel-mode drivers, not user-mode apps.
The professional caveat: version strings are self-reported by the OS and can be wrong after a failed upgrade rollback. When a user reports "Windows 11 24H2" and behavior contradicts it, verify with systeminfo in an elevated command prompt, which pulls from the same source but cross-checks the hotfix list. If the hotfix list is empty on a machine that should be patched, treat the install as suspect.
Practical actions: reading and recording your version
For a single machine, use this sequence.
Press Windows key + R, type winver, and record the edition, release, and full build including UBR. Open Settings > System > About and record System type (x64 or ARM64) and the install date. Run systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Type" in Command Prompt for a scriptable readout. For fleet work, run Get-ComputerInfo | Select WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture in PowerShell. Cross-check the build against Microsoft's Windows release health page; if your UBR is more than two monthly cycles behind, run Windows Update and check for a paused update.
For decisions, apply thresholds explicitly. If the machine runs Windows 10 and is not enrolled in Extended Security Updates, plan migration now; consumer ESU coverage is time-limited and priced at USD 30 for the first year. If the edition is Home and you need BitLocker or Hyper-V, an in-place edition upgrade to Pro is the fix, not a reinstall. If the architecture is ARM64 and an installer fails, check whether the app ships ARM64 or relies on a kernel driver before assuming emulation is at fault. If the release is 23H2 Home, confirm it is still inside its 24-month servicing window before deferring updates.
Limits of self-reported version data
Version strings describe the OS image, not its integrity. A machine can report the correct build while a corrupted component store or a tampered licensing service produces behavior that contradicts the string. System File Checker and DISM report on that layer separately; version data will not reveal it. Version reporting also says nothing about driver versions, firmware, or the Secure Boot state, each of which independently breaks installers and updates. And because Microsoft can change where identifiers live (the winver search shortcut removal is one example), any single method can go stale. Cross-checking two independent methods, such as winver plus msinfo32 or PowerShell, is the reliable habit. The number you cite should always include the UBR, because that is the digit a support engineer actually needs to reproduce your patch state.