How Do I Know Which Windows Version I Have: A Layer-by-Layer Diagnostic Guide

You can identify your Windows version in under thirty seconds by opening Settings, then System, then About, where the "Windows specifications" panel lists the edition, version number, and OS build. If Settings will not open, run the command winver from the Run dialog (Windows key plus R), or type ver into Command Prompt, which prints the same version string in text form.

That answer covers the standard case. What follows explains why three different numbers describe the same installation, why "Windows 11" and "22H2" are not the same kind of label, and which number actually matters when you are troubleshooting a driver, checking update eligibility, or verifying a support deadline. Most short explainers collapse these distinctions; keeping them separate is the entire skill.

What the three version numbers actually mean

Every modern Windows installation carries three independent identifiers, and they answer different questions. The version name (Windows 10 or Windows 11) is a marketing tier that determines which feature set and support lifecycle apply. The version number in YYH2 format (such as 22H2 or 23H2) marks a platform release train, where "H2" means the second half of that calendar year. The OS build is a five-digit engineering number (such as 22631) that increments with every cumulative update and patch.

The mechanism behind this layering matters. Windows Update ships two kinds of payloads. Feature updates change the version number and occasionally the product name; they arrive once or twice a year and install like a full operating system upgrade. Quality updates, by contrast, change only the fourth and fifth digits of the build number and deliver security and reliability fixes monthly. This is why two machines both reporting "Windows 11 23H2" can have different build suffixes and different patched states. The version tells you which train the machine is on; the build tells you where it sits on that train.

There is a counterintuitive detail here that trips up even experienced technicians. The ver command in Command Prompt reports only the major and minor kernel numbers (10.0), not the build. On Windows 11 it returns "10.0.22631" style strings or, on some legacy paths, just "10.0." So Command Prompt is the least reliable of all the built-in tools for distinguishing Windows 10 from Windows 11. Use winver or System Information (msinfo32) instead, because both surface the full build number and the product name side by side.

One plain-language way to hold it: the version name is the car model, the version number is the model year, and the build is the odometer reading.

How the identification tools compare

Five built-in methods can report your version, and they disagree in informative ways. The table below summarizes what each tool shows, what it hides, and which diagnostic job it suits.

The gaps are not bugs. They reflect when each tool was designed and what it was built to answer. The ver command dates to an era when the kernel number alone was a meaningful differentiator, so it has never been updated to expose the feature-update train. Settings and winver were built for end users and therefore prioritize the human-readable product name. PowerShell and msinfo32 were built for administrators and return structured fields you can parse across a fleet.

A professional caveat worth internalizing: on machines that received an in-place upgrade, the registry's CurrentVersion keys and the folder named C:\Windows.old can disagree with what the live system reports. Trust the live query, not the registry or the leftover folder. Faulty diagnostics often trace to a technician reading a stale registry hive rather than the running build.

Quantified context: why the build number is the number that matters

Microsoft ships monthly cumulative updates on the second Tuesday of each month, commonly called Patch Tuesday. Over a typical year that means roughly twelve quality-update events, each pushing the build's trailing digits upward. A machine that has skipped three months of updates and a machine that is fully patched can both read "Windows 11 23H2" in the marketing sense while differing by dozens of underlying fixes. This is the practical reason a support agent asks for the exact build, not just the version.

Support lifecycles also key to the version number rather than the name alone. Each Windows 10 feature-update train carried its own end-of-servicing date, and Microsoft ended standard support for Windows 10 broadly in October 2025, so any Windows 10 build now receives only extended or no updates depending on the arrangement in place. Windows 11 feature trains are supported for a defined window that is measured in months, not years, and the effective support date depends on which YYH2 train you are actually on. Do not present a single "Windows 10 is supported until date X" answer as universal, because the date depends on the specific train and how the machine is enrolled.

For troubleshooting, the build number is the primary key. Driver vendors publish compatibility against specific build ranges. Enterprise management tools filter devices by build to stage deployments. When someone says "update to the latest version," they usually mean the latest build within your current train, not a feature upgrade to a new train. Knowing which number you hold is what lets you tell those two requests apart.

Timeline of a single installation's life

The table below traces the identifiers on one machine from purchase through several years of use, which shows why a single "version" label is a moving target.

The takeaway is structural: the version name is stable for years, the version number changes every six to twelve months, and the build changes monthly. If you record only the name, you have recorded almost nothing diagnostic. If you record the version number and build together, you have a precise fingerprint of the machine's software state at that moment.

Common misconceptions and edge cases

The single most common misconception is that "Windows 10" and "Windows 11" are the only two answers that ever matter. They do matter for eligibility, but they tell you nothing about whether a specific security fix is present. A Windows 11 machine on an outdated build is more exposed in some ways than a fully patched Windows 10 machine, because the fix level, not the brand name, governs patched status. Answering only the name question satisfies curiosity but misses the diagnostic question behind it.

Another edge case: virtual machines and remote sessions. A VM reports the guest operating system's version, not the host's, so a user remoting into a server may see a different Windows version than the laptop in front of them. This causes genuine confusion in support calls and is worth checking before assuming the user misread the screen.

Red flags that suggest you are reading the wrong number:

A build number reported by ver that lacks a product name distinction, indicating kernel-only output. A version number in the registry that differs from what Settings shows, indicating a stale hive after an upgrade. A C:\Windows.old folder whose contents suggest a prior major version, which does not reflect the current install. A Windows 10 build still receiving no updates, which signals a train past end of servicing. An edition string (Home, Pro, Enterprise) mistaken for a version, which answers licensing rather than release.

A lesser-known edge case involves Windows Server. Server builds share the same kernel numbering scheme as client Windows but carry separate product names and separate support timelines. A server build can read "Windows Server 2022" alongside a version number that resembles a client train. If you are inventorying mixed fleets, filter by product name first, then by build, or you will misclassify servers as desktops.

Practical actions: verifying and recording your version

Use this sequence to get a trustworthy answer and to record it correctly for future reference.

Step one: open Settings, then System, then About. Read the three lines under "Windows specifications" and write down the product name, the version number in YYH2 format, and the full OS build including trailing digits. This is your fingerprint.

Step two: if Settings is unavailable or frozen, press Windows key plus R, type winver, and press Enter. The dialog shows the same information in a smaller footprint and works even when the Settings app is broken.

Step three: for a scripted or remote check, run Get-ComputerInfo | Select-Object OsName, OsVersion, WindowsBuildLabEx in PowerShell. This returns structured fields you can log or paste into a support ticket without transcription errors.

Step four: compare your build against the latest build published for your train. If your trailing digits lag the current release by more than one monthly cycle, check Windows Update before assuming the machine is current.

Step five: for machines you manage in bulk, inventory by build, not by product name. Grouping by build lets you target the exact devices that need a patch and avoids pushing updates to already-current machines.

Step six: when a support agent or vendor asks "which version," give them all three identifiers in one line, for example: Windows 11, 23H2, build 22631.4169. One line prevents two rounds of follow-up questions.

Thresholds worth remembering: a single missed Patch Tuesday means trailing digits are one release behind; three consecutive missed cycles is a reasonable trigger to investigate update failures; and a feature-update train past its end-of-servicing window should be treated as unsupported regardless of what the product name says.

Limitations of every method

No built-in tool tells you the full patch history of a machine in one glance, and the version number cannot by itself confirm that a specific fix is installed. You can confirm the current build, but proving that a particular update landed requires checking the installed-updates list or the update history, which is a separate task. The registry approach is especially prone to staleness after in-place upgrades and should never be the sole source in a diagnostic. And on machines managed by an organization, the version you see may be pinned by policy rather than reflecting the latest available release, so the "newest" answer for a managed device is the one your administrator controls, not the one Microsoft publishes.

For ordinary personal machines, the Settings and winver methods are authoritative and sufficient for almost every question. The deeper layers matter when you are resolving a compatibility problem, auditing a fleet, or checking whether a machine has fallen out of servicing. Knowing all three numbers, and knowing which one answers which question, is what separates a real answer from a guess.

This article is general educational information about software identification, not technical support for a specific machine or configuration. It does not substitute for guidance from a qualified IT professional or your device administrator, and it makes no promise about update availability or support outcomes. For systems under organizational management, follow your administrator's instructions rather than the general steps above.