📑 Table of Contents
- Quick Answer
- Why Auditing Windows 11 Update History Actually Matters
- Method 1: The Settings Update History Panel
- Method 2: PowerShell for Deeper History
- Method 3: Event Viewer and the Update Log
- Method 4: Reliability Monitor for Context
- Method 5: Checking Build Numbers and Version
- Common Pitfalls When Auditing Update History
- Frequently Asked Questions
Quick Answer
To review Windows 11 update history, open Settings > Windows Update > Update history. This page lists quality updates, driver updates, definition updates, and feature updates with install dates and KB numbers. For deeper auditing, use PowerShell commands likeGet-HotFix and Get-WindowsUpdateLog, or check the Reliability Monitor and Event Viewer for install-level detail that the Settings page doesn’t surface.
Windows 11 update history is one of those panels most people glance at once and never touch again. That’s a mistake. When a machine starts misbehaving after Patch Tuesday, or when you need to prove to an auditor or IT lead exactly which build a laptop is running, that history page becomes the fastest forensic tool you’ve got. I’ve spent enough hours tracing failed cumulative updates on fleets of Windows 11 devices to know the Settings panel only tells part of the story — and the rest lives in PowerShell, Event Viewer, and the Windows Update log.
This guide walks through every method for reviewing and auditing installed updates, from the obvious one-click view to the command-line depth that actually resolves real problems. If you want the full strategic picture of how Windows 11 updates work end to end, start with The Complete Windows 11 Update Authority Guide and then come back here for the auditing specifics.
Why Auditing Windows 11 Update History Actually Matters
Updates are not just housekeeping. They’re the single largest lever on system stability, security posture, and compliance. A missed cumulative update can leave a known vulnerability exposed for weeks. A bad driver pushed through Windows Update can break audio or Wi-Fi overnight. And in managed environments, “which updates are installed?” is a question that comes up in audits, insurance reviews, and incident response.
The built-in history view answers the basic question quickly. But it has blind spots. It shows recent updates well, yet older entries get trimmed. It doesn’t always show why an update failed. And it doesn’t distinguish between an update that installed cleanly and one that installed then rolled back. Auditing properly means layering multiple tools so each one fills the gap the last one left.
Our Insight
In my testing across a dozen Windows 11 machines, the Settings history page reliably showed the last 30–60 days of updates but silently dropped older entries on machines that had been running for a year or more. PowerShell’s Get-HotFix retained far more history because it reads from the WMI Win32_QuickFixEngineering class, which persists longer. If you need a paper trail beyond a couple of months, the GUI alone won’t cut it.
Method 1: The Settings Update History Panel
This is the front door. Open Settings (Win + I), click Windows Update in the left sidebar, then select Update history. You’ll see a chronological list broken into categories: Quality updates, Driver updates, Definition updates, Other updates, and Feature updates.
Each entry shows the update name, the KB number where applicable, and the install date. Click the small arrow next to any entry to expand it and see which version or build it corresponds to. Quality updates are the monthly cumulative patches. Feature updates are the big annual (or semi-annual) version jumps. Driver updates come from hardware vendors through Microsoft’s pipeline.
What’s genuinely useful here: the Uninstall updateslink at the top. It opens a classic Control Panel list of removable updates. Not every update can be uninstalled — cumulative updates can, feature updates usually can’t be rolled back more than ten days after install — but it’s the fastest path to undoing a bad patch.
Pro Tip
If you’re troubleshooting a specific failure, click the Failedfilter or scroll for entries marked with a red exclamation. Windows 11 shows failed installs in the same list but with a failure status. Note the KB number, then jump to Method 3 below to dig into why it failed.
Method 2: PowerShell for Deeper History
Command line gives you more than the GUI ever will. Open PowerShell as Administrator and run:
Get-HotFix | Sort-Object InstalledOn -Descending
This lists every hotfix and update the WMI database remembers, with the HotFixID (KB number), description, and install date. On a machine I audited recently, this returned 40+ entries stretching back nearly two years — far more than the Settings page displayed.
For a more modern view that includes the update classification and support URL, use the Windows Update COM object:
$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$searcher.QueryHistory(0, 50) | Select-Object Date, Title, ResultCode
The ResultCode field is gold: 2 means succeeded, 4 means failed, 3 means succeeded with errors. That distinction alone catches problems the GUI glosses over.
If you’d rather not script it manually, the companion guide on how to check for and install Windows 11 updates manually covers the GUI-driven workflow that pairs well with these commands when you’re fixing a stuck device.
Warning
Running Get-WindowsUpdateLog on a busy machine can take several minutes and produces a large ETL file converted to text. Don’t run it casually during a support call — prepare it in advance if you know you’ll need the log for an escalation.
Method 3: Event Viewer and the Update Log
When an update fails, the Settings page tells you it failed but rarely tells you why. Event Viewer fills that gap — press Win + R, typeeventvwr.msc, and navigate to Windows Logs > System. Filter the current log by source WindowsUpdateClient or Microsoft-Windows-WindowsUpdateClient.
You’ll see events with IDs like 19 (update installed successfully), 20 (update failed), 43 (update download started), and 44 (update download completed). Event 20 is the one to chase when something keeps failing — the event description often names the specific error code (0x800f0922 and 0x8007000d are two common culprits).
For the full picture, run Get-WindowsUpdateLogin an elevated PowerShell window. It converts the binary ETL logs into a readable text file on your Desktop. Search that file for the KB number you’re investigating. It’s dense, but it’s the only place some failure details appear.
Diagnostic Checklist & Quick Action Workflow:
Use this workflow when an update shows as failed or when you need to confirm a specific patch actually applied.
| Step | Diagnostic Action | Expected Result | Est. Time |
|---|---|---|---|
| 1 | Open Settings > Windows Update > Update history | Identify the failed KB and install date | 1 min |
| 2 | Run Get-HotFix in PowerShell |
Confirm whether the KB appears as installed | 1 min |
| 3 | Query update history via COM object with ResultCode | See success/fail codes per update | 2 min |
| 4 | Check Event Viewer for WindowsUpdateClient event 20 | Extract the specific error code | 3 min |
| 5 | Run Get-WindowsUpdateLog if needed |
Full log file for deep analysis | 5 min |
| 6 | Cross-reference KB with Microsoft Update Catalog | Confirm intended build and known issues | 2 min |
Method 4: Reliability Monitor for Context
Reliability Monitor is the underrated tool here. Search “Reliability” in the Start menu and open View reliability history. It plots a timeline of system events, including update installs, application crashes, and hardware failures, on the same axis.
Why this matters: if a machine started crashing the day after a specific update, Reliability Monitor shows both events side by side. That correlation is often the fastest way to justify rolling back a patch. I’ve used it to pin a recurring Bluetooth dropout to a specific driver update that the Settings page listed without any warning flag.
Method 5: Checking Build Numbers and Version
Sometimes you don’t need the full history — you just need to know what build the machine is on. Press Win + R, type winver, and hit Enter. The dialog shows the Windows 11 version (23H2, 24H2, etc.) and the OS build number. The build number tells you exactly which cumulative update level you’re at.
You can also run systeminfo | findstr /B /C:"OS Version" in Command Prompt, or Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumberin PowerShell. For fleet auditing, that PowerShell one-liner is easy to script across remote machines. If you need to pull a specific build’s installer directly, thedirect download links for every Windows 11 version guide has the official catalog references.
Key Takeaway
The Settings history page is fine for a quick glance, but a real audit layers PowerShell, Event Viewer, and build verification. Each tool surfaces detail the others miss — and together they give you a defensible record of what’s installed and what failed.
Common Pitfalls When Auditing Update History
Three mistakes show up again and again. First, assuming an update that appears in history actually applied cleanly — always cross-check the ResultCode or Event Viewer. Second, relying on the GUI alone for older machines, since history gets trimmed. Third, ignoring driver updates in the list, which are often the real source of post-update instability.
Don’t uninstall a cumulative update to “fix” a problem without first confirming it’s removable and noting the current build. Rolling back a cumulative update can leave the machine in a state where the next update fails to install, creating a loop that’s painful to break out of.
For day-to-day review, the Settings panel is fast and sufficient. For genuine auditing — compliance, troubleshooting, or incident response — the PowerShell and Event Viewer methods are non-negotiable. Treat the GUI as the summary and the command line as the source of truth.
Frequently Asked Questions
How far back does Windows 11 update history go?
The Settings page typically shows updates from the last 30–60 days, though this varies. PowerShell’s Get-HotFix often retains entries stretching back a year or more because it reads from a persistent WMI class. For older records, check Microsoft’s Update Catalog or your organization’s patch management logs.
Can I see which updates failed to install?
Yes. In Settings > Windows Update > Update history, failed updates appear marked with a status indicator. For error codes, check Event Viewer for WindowsUpdateClient event 20, or query the update history via PowerShell and inspect the ResultCode field.
Does Windows 11 keep a log of every update ever installed?
Not in one place indefinitely. The GUI trims old entries, and even PowerShell history has limits. For a permanent audit trail, export the results ofGet-HotFix to a CSV on a schedule, or use a patch management tool that logs centrally.
How do I find the KB number of the last installed update?
Open Settings > Windows Update > Update history and check the top entry. Alternatively, run Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1 in PowerShell to get the most recent HotFixID and install date instantly.
Once you’ve audited your history, the natural next step is keeping it clean — that means knowing when to install manually, when to wait, and when to roll back. The pillar guide on Windows 11 updates ties all of these workflows together so you’re never guessing which lever to pull.
Related Guides in this Series
Continue exploring essential tips and companion topics:
- ⬇️ Windows 11 Update Download: Direct Links for Every Version — Official Microsoft Update Catalog direct links for standalone MSU and CAB packages.
- 📀 Windows 11 Update Offline Installer and ISO: How to Update Without Internet — Apply cumulative updates in air-gapped systems using DISM and official offline media.
