Four sources disagree about your update history: which one can answer which question

An auditor asks something trivial. Is the August cumulative update on this device, and when did it install?

You pick one of four ways to answer and close the ticket. Then somebody answers from a different source and gets a different date. Neither of you is wrong, and neither can explain the gap.

The problem: four sources, four answers, one device

Everything below was measured read-only on one Windows 11 Enterprise machine, build 26200.9168, DisplayVersion 25H2, on 23 August 2026.

Three sources, three shapes of answer. Get-HotFix gave a date with no time. The WUA history gave a timestamp to the second, on a different day. The component store did not recognise the KB at all. None of that is an error - each is a correct answer to a question that is not quite the one that was asked.

The gap between four rows and 153 is the difference between "which CBS packages are installed" and "what did the agent try to do". Treat them as interchangeable and you are wrong both ways.

Why it happens: each source records a different event

Source 1: Get-HotFix only ever sees CBS

The Win32_QuickFixEngineering reference states it in one sentence: "This class returns only the updates supplied by Component Based Servicing (CBS). These updates are not listed in the registry. Updates supplied by Microsoft Windows Installer (MSI) or the Windows update site (https://update.microsoft.com) are not returned by Win32_QuickFixEngineering."

The Get-HotFix help repeats that paragraph verbatim in its Notes - stated twice, in the two places an admin looks, and still the most commonly ignored fact in Windows patch reporting.

What falls outside CBS on a normal corporate device? On mine the WUA history recorded all of these as installed, and not one appears in Get-HotFix: the .NET 8 runtime update KB5122104, PowerShell 7.6.5, the Malicious Software Removal Tool KB890830, Defender security intelligence KB2267602, and five vendor driver updates.

There is a stranger detail in the same class definition. The MOF maps HotFixID to a MappingStrings qualifier of Win32Registry|SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix - while the prose above says these updates "are not listed in the registry". Both are true, and the resolution is measurable.

Source 2: the WUA history is a per-attempt event log in a database you have been told to delete

The COM entry point is IUpdateSearcher::QueryHistory(startIndex, count, retval), implemented in wuapi.dll. It returns an IUpdateHistoryEntryCollection documented as containing "matching event records on the computer in descending chronological order".

Read the companion method name carefully. GetTotalHistoryCount returns "the number of update events on the computer" - not updates. That one word is the whole behaviour: an update that retries forty-one times produces forty-one rows.

Not hypothetical. KB5074109 accounts for 41 of my 153 rows, every one orcFailed with 0x80240034, and there is no success row for it anywhere. It was never installed - a later cumulative update superseded it and the retries stopped.

The store behind all of this is C:\Windows\SoftwareDistribution\DataStore\DataStore.edb, 54.75 MB here, with a documented error family of its own: the WU_E_DS_* codes, 0x80248000 to 0x80248FFF. It is also the first thing every troubleshooting script deletes.

Source 3: the component store knows components, not KBs

Get-WindowsPackage -Online returned 415 rows, and the state split is what no other source exposes.

Only one of 415 names carries a KB number, and it is the enablement package. Everything else is named by component and version: the August servicing stack update is Package_for_ServicingStack_9156~31bf3856ad364e35~amd64~~26100.9156.1.0. No KB, even though Get-HotFix lists it as KB5123304.

So the store cannot answer "is KB X installed" by name. What it can answer, and nothing else can, is which component versions are present and in which of three states. The DISM API documents these as DismPackageFeatureState: DismStateStaged (2), DismStateInstalled (4), DismStateSuperseded (6), plus DismStateNotPresent (0), DismStateUninstallPending (1), DismStateRemoved (3), DismStateInstallPending (5) and DismStatePartiallyInstalled (7).

Those 95 Staged packages are why this source exists: the payload is on disk and CBS has not promoted it. Nothing else distinguishes "downloaded" from "running".

Source 4: Settings is a view, not a record

Admins cite the Settings page as an independent authority. Microsoft's guidance describes the plumbing: "The Settings UI communicates with the Update Orchestrator service that in turn communicates with to Windows Update service."

So it is a client of the same agent, reading the same datastore, presented in categories. The documented UI error family is the giveaway: 0x80243001, 0x80243002 and 0x80243003 - the WU_E_INSTALLATION_RESULTS_* codes - all describe results that "couldn't be read from the registry". The UI has its own read path and its own ways to fail.

It inherits every limitation of source 2 and adds one: you cannot query, filter, export or join it. Use it to confirm what a user saw, never what a device did.

The binaries doing the work

How to verify: read all four before you conclude anything

Here is the order I use. Every destructive option comes after every read-only one.

1. Establish the release facts. CurrentBuild, UBR, DisplayVersion - a KB maps to different builds on different releases.
2. Run Get-HotFix and treat it as a floor, not a total. MSI, Store, driver and Defender content is missing by design.
3. Pull the full WUA history and count events, not updates. Group by Title first, or retries distort every number.
4. Decode ResultCode and Operation with the documented enums, not by eye.
5. Check ClientApplicationID before blaming Windows Update. Here, 43 of 153 events came from setup and Store installers.
6. Find the datastore horizon. Compare DataStore.edb's CreationTime with the oldest history row. Anything earlier is invisible to sources 2 and 4, permanently.
7. Take the component-store census. Your only view of Staged and Superseded.
8. Only now read the Setup log for the KB in dispute. That turns four disagreeing numbers into one chronology.

Two closed enums decode every row.

UpdateOperation has exactly two members: uoInstallation (1) and uoUninstallation (2). There is no third. All 153 rows here were uoInstallation, which answers a question people ask this API by mistake - the history shows an uninstall only if WUA performed it. A wusa /uninstall or a boot-time CBS rollback leaves no uoUninstallation row at all.

A third enum governs attribution, and trips people up constantly.

Every history row here reported ServerSelection = 3. Read casually, ssOthers sounds alarming on a managed device. It is not. The documentation tells you what to do next: read ServiceID. The KB5121003 row carried 8b24b027-1dee-babb-9a95-3517dfb9c552.

The Setup log survives that reset, making it the one durable per-KB chronology on the machine. Microsoft publishes no event-ID catalog for the Microsoft-Windows-Servicing provider, so this table comes from the on-disk manifest and IDs observed live.

That is the reconciliation. CBS moved KB5121003 from Absent to Staged on the 19th, began the promotion to Installed, hit the reboot boundary at 18:37:47, and finished at 09:14:13 the next morning. The WUA history recorded orcSucceeded ten seconds into that gap. Get-HotFix reports InstalledOn = 8/20/2026, agreeing with CBS.

So the "wrong" date was never wrong. The WUA history dated the agent's work; Get-HotFix dated the package reaching its final state; those two events were 14 hours 36 minutes apart.

The fix: match the source to the question

No script makes these four agree. The fix is to stop asking one source a question it cannot answer.

Why a rolled-back update reads as succeeded-then-absent

An orcSucceeded row records that the install operation completed. The enum's own preamble says so: OperationResultCode "Defines the possible results of a download, install, uninstall, or verification operation on an update". The operation, not the end state.

For a CBS update the operation finishes when the package is staged and the promotion queued. The rest happens at reboot, outside that operation, and Microsoft documents that phase separately in the update-handler family: 0x80242014 WU_E_UH_POSTREBOOTSTILLPENDING ("The post-reboot operation for the update is still in progress"), 0x80242015 WU_E_UH_POSTREBOOTRESULTUNKNOWN and 0x80242016 WU_E_UH_POSTREBOOTUNEXPECTEDSTATE. There is even a documented success code that says the job is not done: 0x00240005 WU_S_REBOOT_REQUIRED, "The system must be restarted to complete installation of the update."

So if the boot-time promotion fails and CBS reverses it, you get my timeline with a different ending: a permanent orcSucceeded row dated the 19th, no Get-HotFix entry, the package back to Absent in the store, and a Setup log showing the transition attempted and undone. Succeeded, then absent. Both records correct.

Critically, IUpdateHistoryEntry exposes no reboot-required property. Its members are ClientApplicationID, Date, Description, HResult, Operation, ResultCode, ServerSelection, ServiceID, SupportUrl, Title, UninstallationNotes, UninstallationSteps, UnmappedResultCode and UpdateIdentity, with Categories added by IUpdateHistoryEntry2. Nothing there separates a final success from a provisional one. You have to go to the Setup log.

And do not treat orcFailed as evidence of a broken device. Microsoft's guidance on transient load-shedding states that callers "would get orcFailed or orcSucceededWithErrors" and that "Retrying the operation later is expected to succeed". A single failed row means nothing. Forty-one identical failed rows with no success row, as with KB5074109, means something specific - and you see it only because the history keeps every attempt.

Proof it worked: the reconciliation on a real device

You understand these four sources when you can predict what each will say before you run it. Here is the final pass.

First, the timezone. QueryHistory returned Kind = Unspecified - the API declines to say which clock it used, and the get_Date documentation says only "Gets the date and the time an update was applied". Measured against the Setup log for the same package it is one hour behind local time, on a device in GMT Standard Time during summer time. That is UTC. If you have ever seen a report where the WUA date is an hour or a day off the event log, this is why.

Second, the horizon. DataStore.edb was created on 17 February 2026 at 12:16:02; the oldest surviving history event is 18 February at 11:22:24. The enablement package that took this device to 25H2 installed on 4 February, two weeks before that file existed. Get-HotFix still reports it, because CBS state is not kept in the datastore. The WUA history reports nothing, and never will.

Third, the bounds. The documented remark on QueryHistory is that it "returns WU_E_INVALIDINDEX if the startIndex parameter is less than 0 (zero) or if the Count parameter is less than or equal to 0 (zero)". Both cases raised 0x80240007 exactly as written, and asking for 100,000 rows when 153 exist returned 153 with no error - so the safe idiom really is QueryHistory(0, GetTotalHistoryCount()).

Nothing was fixed here, and nothing needed to be. Four numbers that looked contradictory - 4, 153, 415, and a one-day date gap - now have a single explanation, and every one can be defended to an auditor. That is what a diagnosis is.

References

• Win32_QuickFixEngineering class
• Get-HotFix
• IUpdateSearcher::QueryHistory
• IUpdateSearcher::GetTotalHistoryCount
• IUpdateHistoryEntry and IUpdateHistoryEntry2
• OperationResultCode enumeration
• UpdateOperation enumeration
• ServerSelection enumeration
• Windows Update error code list by component - the WU_E_UH_POSTREBOOT* family
• Additional resources for Windows Update - the reset steps and their ordering
• Windows Update issues troubleshooting - Settings/USO plumbing, DCAT, load shedding
• DismPackageFeatureState enumeration
• Get-WindowsPackage
• KB5054156: Feature update to Windows 11, version 25H2 by using an enablement package