Quick fix: The Settings → Windows Update → Update history view sometimes hides older entries. Run wmic qfe list in Terminal to see the full installed-KB list, or query the Windows Update history programmatically via PowerShell’s Get-HotFix for an authoritative record.
You go to Settings → Windows Update → Update history to check whether a specific KB installed. The list shows only the past month, or only Quality Updates without Cumulative ones, or has gaps. Windows’s Settings UI for update history is incomplete — the actual full record exists, but the UI doesn’t show it. Two reliable alternatives give you the real list.
Affects: Windows 11 (and Windows 10) Settings app.
Fix time: ~5 minutes.
What causes this
Windows tracks installed updates in three places: the CBS (Component-Based Servicing) log at C:\Windows\Logs\CBS\, the WindowsUpdate.log in C:\Windows\WindowsUpdate.log (or via PowerShell on newer versions), and the WMI Win32_QuickFixEngineering class. Settings → Update history reads from the Windows Update agent’s session history, which can be cleared or filtered, leaving the UI incomplete while the actual records remain.
The WMI table is authoritative for installed hotfixes. PowerShell’s Get-HotFix and CMD’s wmic qfe list read this and show the full list.
Method 1: Use Get-HotFix in PowerShell
The fastest way to get the authoritative update list.
- Open Terminal. Doesn’t need admin rights.
- Run:
Get-HotFix | Sort-Object InstalledOn -DescendingOutput shows every installed update with KB number, installation date, and description.
- For just the date range:
Get-HotFix | Where-Object { $_.InstalledOn -gt (Get-Date).AddDays(-90) } | Format-Table HotFixID, InstalledOn, DescriptionFilters to the last 90 days.
- Export to CSV:
Get-HotFix | Export-Csv updates.csv -NoTypeInformation. - For the underlying WMI data:
Get-CimInstance Win32_QuickFixEngineering | Format-List *. Shows additional fields like FixComments and CSName. - Search for a specific KB:
Get-HotFix -Id KB5012345. Returns whether installed and when.
This is the canonical method for sysadmins. Output is parseable and complete.
Method 2: View Windows Update history via PowerShell session history
For when you want to see the full UI-equivalent history, not just hotfixes.
- Open Terminal (Admin).
- Run:
$Session = New-Object -ComObject Microsoft.Update.Session $Searcher = $Session.CreateUpdateSearcher() $historyCount = $Searcher.GetTotalHistoryCount() $Searcher.QueryHistory(0, $historyCount) | Select-Object Date, Title, ResultCode, Description | Format-Table -AutoSizeThis queries the Windows Update Agent COM API for every recorded update session, including failures.
- The ResultCode column: 1 = In progress, 2 = Succeeded, 3 = Succeeded with errors, 4 = Failed, 5 = Aborted.
- Export to file:
$Searcher.QueryHistory(0, $historyCount) | Export-Csv update-history.csv -NoTypeInformation - This output matches what Settings → Update history would show if it weren’t filtered.
- For an even more detailed look at update sessions: read
C:\Windows\SoftwareDistribution\ReportingEvents.logdirectly. Each line is an Update Agent event with timestamp.
This is the right approach when you need to verify what Settings is hiding or filtering.
Method 3: Restore the Settings UI’s view
For when the Settings page itself is empty or stuck.
- Open Terminal (Admin). Stop the Windows Update service:
net stop wuauserv net stop bits - Reset the SoftwareDistribution folder:
cd C:\Windows ren SoftwareDistribution SoftwareDistribution.old - Restart services:
net start wuauserv net start bits - Windows recreates SoftwareDistribution and the session history starts fresh.
- Reopen Settings → Windows Update → Update history. Old entries are no longer visible (because we renamed the folder), but new updates will populate the list correctly from this point.
- To preserve the old history: don’t delete
SoftwareDistribution.old— you can still query its data via the COM method in Method 2 even after resetting the active folder. - If the Settings page is corrupted but you want to keep history: reset the Settings app instead. Settings → Apps → Installed apps → Microsoft Settings → Advanced options → Reset.
The trade-off: resetting wipes the visible history in Settings. Use only when Settings is the problem, not the data.
How to verify the fix worked
- Run
Get-HotFix | Measure-Object | Select-Object Count. Output shows the total count of installed hotfixes — should be 50–500+ on a long-running install. - Cross-reference: pick a KB from the list and search microsoft.com/kb. The article should match the description shown by Get-HotFix.
- If you ran Method 2: the output should include entries dating back to first install of Windows on this PC.
If none of these work
If Get-HotFix returns empty or just a few entries, the WMI repository may be corrupted. Rebuild WMI: open Terminal (Admin) and run winmgmt /verifyrepository. If it reports inconsistency: winmgmt /salvagerepository, then reboot. If neither works, the deep fix is net stop winmgmt && cd C:\Windows\System32\wbem && ren Repository Repository.old && net start winmgmt — this resets WMI but loses some metadata. For corrupted SoftwareDistribution: ran Method 3’s rename trick but new updates don’t install? Run DISM /Online /Cleanup-Image /RestoreHealth and sfc /scannow to repair the Windows Update infrastructure. For PCs upgraded from Windows 10: the Update history sometimes loses entries from the previous Windows version; this is expected. Cross-check via Get-HotFix which retains records across upgrades. For domain-joined PCs with SCCM/Intune deployment: the local Update history shows only client-initiated installs; SCCM-pushed updates appear in the SCCM client log instead (C:\Windows\CCM\Logs\UpdatesDeployment.log).
Bottom line: Get-HotFix in PowerShell shows the authoritative update list when Settings’ UI is incomplete. The COM API gives the full session history including failed installs. Trust these over the Settings UI.