To check which Windows version you have, press Windows key + R, type winver, and press Enter. A small dialog displays your edition (Home, Pro, Enterprise), version number (such as 24H2), and OS build number. Alternatively, open Settings > System > About, or run the command ver in Command Prompt. The build number is the decisive identifier, because it determines your update channel, security support window, and feature availability more precisely than the marketing version name.
What Windows Version Actually Means
A Windows version is not one number but a stack of four identifiers that answer different questions. The product name (Windows 11) tells you the generation. The version number (24H2) tells you which annual feature release you are on. The OS build number (for example, 26100.3194) tells you the exact code state, including cumulative patches. The edition (Home, Pro, Enterprise, Education) tells you which features are licensed.
These identifiers update on different schedules, which is why two machines both "running Windows 11" can behave differently. The feature update changes the version and the first part of the build number. Monthly cumulative updates change only the part after the decimal point. Edition changes only when you change your license.
The mechanism behind this layering is Microsoft's servicing model. Since Windows 10, Microsoft ships one core operating system and turns features on or off through cumulative updates and licensing. The build number is the ground truth the servicing pipeline uses to decide which patches your device receives. If you report a build number to support, they can reconstruct your exact patch state; if you report only "Windows 11," they cannot.
Plain-language version: the product name is the family, the version number is the model year, the build is the exact serial number, and the edition is the trim level.
Where Each Method Reads Its Data
Every method for checking your version ultimately reads the same registry hives or system files, but each surfaces a different subset. Knowing which source each tool queries explains why the numbers sometimes appear to disagree.
The winver dialog reads from the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion, specifically the values CurrentBuild, UBR (Update Build Revision), DisplayVersion, and ProductName. It combines CurrentBuild and UBR into the full build string you see, such as 26100.3194. This is why winver is the fastest reliable check: it reads the authoritative values directly.
Settings > System > About reads the same key but formats the output differently and adds hardware context. The About page also exposes the Windows specification version and the experience pack version, which winver does not show.
The ver command in Command Prompt reads the kernel version through the Windows API, which can lag the registry after certain updates. System Information (msinfo32) and Task Manager's Details tab pull from the same API layer. This is the counterintuitive detail professionals know: the ver command can report a different build than winver on the same machine immediately after a feature update, because the API caches the kernel version at boot.
A professional caveat: remote inventory tools that query WMI (Windows Management Instrumentation) can return stale values if the device has not rebooted since the last feature update. Always confirm with winver on the device itself before making support or compliance decisions.
Reading the Numbers: A Comparison of What You See
The table below maps each identifier to what it controls and how often it changes. Values reflect the stable Windows 11 servicing model.
| Identifier | Example | What it controls | How often it changes |
|---|---|---|---|
| Product name | Windows 11 | Generation and hardware requirements | Every major generation (roughly every 3 years) |
| Version (DisplayVersion) | 24H2 | Annual feature release and support clock | Once per year |
| OS build (CurrentBuild) | 26100 | Feature baseline and servicing branch | Once per feature release |
| UBR (revision) | .3194 | Cumulative security and quality patches | Monthly, sometimes more |
| Edition | Pro | Licensed feature set | Only on license change |
| Experience pack | 1000.26100.x | Out-of-band feature enablement | Irregularly |
The version number format changed with Windows 11. Windows 10 used two-digit half-year codes (1909, 2004, 21H2). Windows 11 moved to a single annual release named by the second half of the calendar year (22H2, 23H2, 24H2). If you see a version like 21H2 on a device claiming to run Windows 11, that is Windows 10, not Windows 11. This is a common misread.
How Support Windows Are Calculated
Support timelines are the practical reason the build number matters. Microsoft services each version on a fixed clock, and the clock starts at the version's release, not at your install date.
For Windows 11 Home and Pro, each annual feature release receives 24 months of security updates. Enterprise and Education editions receive 36 months. Windows 10 version 22H2, the final Windows 10 release, reaches end of support on October 14, 2025 for Home and Pro, with paid Extended Security Updates available afterward for a defined period. These thresholds reconcile simply: consumer editions get two years, business editions get three, and the final release of a generation gets a fixed end date rather than a rolling window.
The timeline table below shows how a single device's support status evolves. Dates are illustrative of the servicing cadence, not a specific machine's history.
| Event | What changes | Effect on support |
|---|---|---|
| Feature update installed | Version and build baseline change | New 24- or 36-month clock starts |
| Monthly cumulative update | UBR increments | Security posture improves; clock unchanged |
| Version reaches end of servicing | No further patches for that build | Device becomes a security liability |
| Edition upgrade (Home to Pro) | Edition value changes | Support window may extend to 36 months |
| Windows 10 end of support | Final patches stop for consumer editions | Extended Security Updates become the only path |
The counterintuitive point: installing the latest cumulative update does not extend your support window. Only moving to a newer feature release resets the clock. A fully patched device on an expired version is still unsupported.
Edge Cases That Break the Simple Answer
Several situations make the standard answer incomplete. Handle these before trusting any single reading.
Devices enrolled in the Windows Insider Program report builds from preview channels (Dev, Beta, Release Preview) that do not map to public version numbers. An Insider build may show a version like 24H2 while running code that will never ship. Check Settings > Windows Update > Windows Insider Program to confirm enrollment.
Windows Server shares build numbers with client Windows but follows a different servicing model and a different support calendar. A build number alone cannot tell you whether a machine runs client or server Windows; the product name and edition disambiguate.
Long-term servicing builds (LTSC) skip annual feature updates entirely and receive up to 5 or 10 years of support depending on the channel. An LTSC device may report an old-looking version number while remaining fully supported.
Virtual machines and golden images can carry stale registry values if sysprep was misconfigured, so a VM may report a build that does not match its actual patch level. Verify inside the guest, not from the host.
Misconceptions Worth Correcting
The most common misconception is that the version name is the build number. They are different fields, and support staff need the build. Saying "I'm on 24H2" narrows the problem; saying "I'm on build 26100.3194" often solves it.
A second misconception is that Windows 11 and Windows 10 can be told apart by the Start menu alone. Visual tweaks have been backported, and customized systems blur the line. The winver dialog settles it in under five seconds.
A third is that a higher build number always means a newer, better-supported system. Insider builds carry higher numbers than public releases but are not production-supported. Build number ordering only holds within the same servicing branch.
Bullet list of red flags that mean you should re-check before acting:
The ver command and winver disagree by more than the UBR revision. The About page shows a version that does not exist in Microsoft's release history. A device reports Enterprise features but the license shows Home. The build is from an Insider channel on a machine you believe is production. The reported build predates the last reboot after a feature update.
Practical Steps to Check and Record Your Version
Use these steps in order, and record the result in a form you can share with support.
First, run winver (Windows key + R, type winver, Enter). Note the version and full build, including the revision after the decimal. Second, open Settings > System > About and confirm the edition matches what you expect. Third, if you manage multiple devices, run systeminfo from an elevated Command Prompt and capture the OS Name, OS Version, and OS Build fields; these export cleanly to a text file for inventory.
For a fleet, use a scripted query against the registry value CurrentBuild and UBR rather than WMI, which can cache. Set a threshold: any device more than 60 days past its version's end-of-servicing date should be flagged for upgrade. Reconcile that 60-day buffer with your organization's patch policy; a stricter policy may use 30 days, a lenient one 90. The point is to pick one number and apply it consistently.
When you contact support, provide four values: product name, version, full build with revision, and edition. This eliminates the most common round of back-and-forth.
Limits of What a Version Check Tells You
A version check tells you the code state, not the health of the device. It cannot reveal pending updates that have downloaded but not installed, driver problems, or configuration drift. It also cannot confirm activation status or license compliance; those live in separate settings.
Build numbers from third-party tools and remote consoles can lag or be misreported, so treat any reading taken remotely as provisional until confirmed on the device. Microsoft's own release health dashboards are the authority on which builds are currently serviced, and those dashboards change; do not treat any single date in this article as a permanent guarantee.
Finally, the version check is a snapshot. On a device receiving monthly updates, the UBR will change within weeks. Re-check before any decision that depends on patch level, and record the date alongside the number.
This article provides general educational information about Windows version identification and support timelines. It is not a diagnosis, treatment plan, legal opinion, or investment recommendation, and it does not promise any outcome or guarantee of support. Support dates and servicing policies can change; confirm current details with Microsoft's official documentation or a qualified IT professional before making compliance or upgrade decisions.