The KB installed fine and is still being offered: supersedence, and why 'applicable' is a separate field

KB5121003 installed on a Wednesday evening. The device took its reboot. On Thursday morning Windows Update offered KB5121003 again.

Nothing failed. There is no error code to look up. The history says the installation succeeded, the build number moved, and the offer is still sitting there — while a compliance dashboard reports the same device as missing the same KB.

This is the failure mode with no error message, which is why it wastes more hours than most of the ones that have one. And almost every response starts by destroying the evidence.

The problem: the update succeeded and the offer came back

The symptom arrives in four costumes, and they are not the same problem.

The first is the honest one. Settings shows the update under Update history as installed and simultaneously shows it as available. Both statements are true at the same moment, and understanding why is most of the work.

The second is a reporting disagreement: your compliance tool says the KB is missing on a device whose build already contains that KB's fixes. Nothing is wrong with the device; something is wrong with the question the tool asked.

The third is a KB superseded months ago, still appearing as required in a WSUS or Configuration Manager view — still in the catalog because supersedence is a lifecycle stage, not a deletion.

The fourth is the genuinely broken one: an update that installs, gets offered, installs again, and loops. That one is real, and you cannot distinguish it from the other three without reading the store.

The four reflexes, and what each one costs you

Search for this symptom and you will be told to do one of four things immediately. Every one removes information you have not read yet.

Reinstall the MSU from the catalog. This tells you nothing about why the offer persisted, and if the reason was a pending reboot you have queued a second copy of work that was already staged.

Uninstall it and put it back. On a modern cumulative update this is not available in the form people imagine, and Microsoft's own wording on that is below.

Delete SoftwareDistribution. That datastore is the record of what the agent evaluated and when. Deleting it forces a full scan, which re-offers everything the rules say is missing — including the exact KB you are investigating. You have removed the evidence and reproduced the symptom.

Run component store cleanup to "get rid of the superseded packages." This is the worst one.

Before touching anything, four questions need answers, and each one has a different source of truth:

1. What build is this device on, and which release does that build belong to?
2. Which package versions exist in the store, and in which state is each one?
3. Does the servicing stack consider the package applicable — a separate field from its state?
4. What did the agent record, and does its timeline agree with the servicing stack's?

Why it happens: three questions that look like one

"Is this KB installed?" feels like one question with a yes or no answer. It is at least three questions, answered by three subsystems that store their answers in three places, in three different vocabularies.

Question one: installed is a package state, not a fact about a KB

The component store does not track KBs. It tracks package identities, and each identity carries a state. Microsoft enumerates exactly eight in the DISM API.

Read what Staged and Superseded actually say. Staged gets one sentence that restates its own name — the documentation genuinely does not explain it, which is why practitioners guess. Superseded says only that a newer version exists. Neither says the package is broken, absent, unneeded, or safe to remove.

Three of the eight states account for the whole inventory on the machine I measured — Windows 11 Enterprise, DisplayVersion 25H2, build 26200.9168, read read-only in one pass:

Four hundred and fifteen against four, and neither tool is broken. Win32_QuickFixEngineering, which is what Get-HotFix reads, states its own scope: it "returns only the updates supplied by Component Based Servicing (CBS)". It is a history list with no state column, so it cannot tell you something is superseded — it has no concept of supersedence.

Broken down by release type, the 199 resolve into something far less dramatic:

Eighty-eight percent of the superseded rows are Feature on Demand payloads, whose metadata every cumulative update revises. Only two superseded rows in the whole store are Windows cumulative updates; the three Update rows are .NET Framework rollups. The scary number was churn in a part of the store nobody was worried about.

One family shows the mechanism at full depth: Microsoft-Windows-FodMetadataServicing-Desktop-Metadata-Package held fourteen Superseded, one Staged and one Installed — sixteen versions of one component, one per servicing event since the image was built. That is a healthy chain.

Question two: superseded does not mean gone, and it does not mean unneeded

On the device, supersedence is a state. On the management plane it is a lifecycle stage with a timer attached, and the two are routinely confused.

Configuration Manager's supersedence rules decide when a superseded update expires — a separate event from being superseded. Microsoft's note on the setting is precise and easy to misread: the "Months to wait before a superseded update is expired" value "is based on the creation date of the superseding update", not on the date the older update was published. Until that timer elapses and the update is declined, it stays in the catalog the client evaluates. And Microsoft's justification for declining them is performance, not correctness: "Declining updates that Configuration Manager marks as superseded further minimizes the catalogs and improves performance."

So a superseded update reported as required is not automatically an error: either the newer update is not approved, the older one has not expired, or the client still evaluates it as needed. Three root causes, one symptom.

Question three: applicable is a separate documented field

When DISM returns detailed information about a package it fills a DismPackageInfo structure, and that structure carries both a state and an applicability flag as independent members:

Two fields, same object, no stated relationship between them. And on the measured device they genuinely disagree with each other's implications — the July cumulative update, sitting in Superseded, reports Applicable : True. So does the August one that superseded it. Being superseded did not make the older package inapplicable; it made it older. "Is this installed?" and "does this apply?" have never been the same query, and a script that answers one while claiming to have answered the other is wrong by construction.

How the agent actually decides: a rule, not a lookup

The Windows Update Agent's default search criteria is exactly this, and it is documented as the default:

It looks like a database query against a list of installed KBs. It is not. Microsoft's own terminology table for the Windows Update scan gives the game away in two entries. A detector update is "a special update that contains IsInstalled applicability rule only and no payload", used for prerequisite evaluation. A category update is "a special detectoid that has an IsInstalled rule that is always true".

IsInstalled is a rule, shipped inside the update's metadata, evaluated against the live device. It can test file versions, registry values, installed packages, or anything else the publisher encoded. The corresponding property on the update object is documented with a careful qualifier that most people skip: it "indicates whether the update is installed on a computer when the search is performed".

That single design decision explains the whole symptom. An update is offered when its rule evaluates false. If the rule keys on a file version that a rollback reverted, on a component that a particular language or architecture child never received, or on a state the device only reaches after a restart, then the KB is installed according to your inventory and not installed according to the rule. Both answers are correct, to different questions.

Applicability also decides what work is even planned: "When an update is applicable, the 'Arbiter' and metadata are downloaded... the Arbiter will gather details from the device, and compare that with the downloaded metadata to create an 'action list'." That list tells "the installation agent (such as CBS or Setup)" what to do. Applicability comes first; the servicing stack only sees its consequences.

One KB is several packages, and the KB number is almost nowhere

The device's August update is a combined package. The KB article says so in Microsoft's standard wording — "Microsoft combines the latest servicing stack update (SSU) for your operating system with the latest cumulative update (LCU)" — and names its passenger explicitly: KB5121003 "Includes KB5123304 (Build 26100.9156), which improves the reliability of the Windows update installation process." That build matched the servicing stack the device had actually loaded, 10.0.26100.9156, exactly.

One KB number, two packages, two install times, two states to check. Mapping the store's cumulative-update family back to KB numbers gave this:

Three things in that table matter more than they look. The KB number lives in the Description field and in a SupportInformation URL — never in the package name. Grep package names for a KB number and you will find nothing, on a device where that KB is definitively installed.

The servicing stack package does not carry a KB number at all; its description reads "Fix for ServicingStack 10.0.26100.9156". The only place the string KB5123304 appears on this device is the Setup event log.

And the oldest entry, Staged, was installed by "DISM Package Manager Provider" with no install time recorded — it went into the image offline at build time, which is exactly why it sits in Staged rather than Superseded. That is KB5043080, the base cumulative update for the original 24H2 image.

Removal is where the "just reinstall it" reflex hits a documented wall. The standard cumulative-update article says removing the LCU requires "the DISM/Remove-Package command line option"; that "Running Windows Update Standalone Installer (wusa.exe) with the /uninstall switch on the combined package will not work because the combined package contains the SSU"; and, flatly, "You cannot remove the SSU from the system after installation." The uninstall-and-reinstall cycle people reach for does not exist for a modern LCU, and combined delivery has been the norm since February 2021 on Windows 10 version 2004 and later.

The UBR trap: same UBR, different build

Now the part that breaks compliance scripts silently. KB5121003's own title is "August 11, 2026—KB5121003 (OS Builds 26200.9168 and 26100.9168)". One KB, one UBR, two builds: 26200.9168 on 25H2 and 26100.9168 on 24H2. Not a one-off: KB5094126 shipped as 26200.8655 and 26100.8655, KB5101650 as 26200.8875 and 26100.8875 — three consecutive months, same pattern.

So a compliance rule of UBR -ge 9168 without also pinning CurrentBuild passes a 24H2 device against a 25H2 baseline. Both report 9168. They are different operating system releases with different support end dates, and only the build number distinguishes them.

The reason is that 24H2 and 25H2 share a servicing branch; 25H2 arrives as an enablement package that switches on code already present. On the measured device that package is still in the store as Package_for_KB5054156~...~26100.6717.1.4, Installed, applied on 4 February 2026 — and even the package that made this device 25H2 is versioned 26100.

Which gives the cleanest measurement in this article. Of 415 package versions on a device whose CurrentBuild is 26200: zero contain 26200, and 411 contain 26100.

The binaries that answer each question

Separate stacks answer these questions, versioned independently of each other and of the OS. Every version below was read off the measured device.

Note the four version families on one machine: the agent at 1509.2607.1012.0, DISM at 10.0.26100.8457, the servicing stack at 10.0.26100.9156, the OS at 10.0.26200.9168. "Is the device up to date" has no single answer here either.

How to verify: read state, applicability and history separately

Seven steps, in this order, all read-only. Do not skip to step four because you already know the build.

Step 1: establish the build identity, not the KB

Everything downstream depends on knowing which release you are on, and all the values live under one key.

Step 2: census the store by state before looking at any single package

The census tells you whether this is a healthy store with normal churn or something genuinely unusual. Cross-tabulate against release type — that is what turns a frightening number into a boring one.

Step 3: read the chain for the family you actually care about

Filter to the cumulative-update family and the servicing stack. Five rows give the OS's whole servicing history.

Step 4: ask the package whether it is applicable

Passing -PackageName switches DISM to the detailed object, where Applicable, Description, InstallClient and SupportInformation appear. This step answers the question in the title.

Two other fields matter. RestartRequired : Possible is the documented DismRestartPossible value — "this package or feature might require a restart", neither a yes nor a no. And InstallClient names who did the work.

Step 5: ask the servicing stack for the state transitions

The Setup event log records every state change by name with the KB number, and it is the only place on the device that names the servicing stack update. Microsoft publishes no event-ID catalog for this provider, so the table below is built from measured entries.

There is the answer, in the log, with timestamps. The servicing stack processed the SSU first through its own Absent to Staged to Installed sequence, then the LCU — exactly what combined-package delivery is documented to do. The LCU then hit the reboot gate and sat in Staged overnight.

Step 6: ask the agent what it recorded

QueryHistory reads the local datastore and triggers no scan, so it is safe to run first. The integers are documented enumerations: ResultCode 2 is orcSucceeded, 4 is orcFailed; Operation 1 is installation.

Step 7: land on a root cause

The fix: pin the build, not the KB

In four of the six rows above, the fix is not on the device. That is the honest conclusion of this diagnostic, and why the diagnostic comes first.

The highest-value change is to stop asking whether a KB is present and start asking whether the build is at or above a floor. A cumulative update is cumulative: if the build is at the floor, the fixes are in, whatever your KB list says.

Second: when a reboot is pending, reboot. Event 4 is not a warning, it is an instruction — the package cannot reach Installed without it. Reinstalling the MSU at that point queues duplicate work and buys you a longer restart.

Third: never run wusa /uninstall against a modern cumulative update. As quoted above, it "will not work because the combined package contains the SSU", removal requires DISM /Remove-Package, and the SSU cannot be removed at all. That is a one-way door.

Fourth: leave the superseded rows alone while investigating — they are the chain. Reclaiming the store is a separate scheduled decision, and /ResetBase permanently removes your ability to uninstall the updates currently installed.

Fifth, for management-plane cases: fix the supersedence and approval rules on the server, not the client — and remember the expiry timer counts from the creation date of the superseding update.

Proof it worked: one KB pair through every lens

Everything below was measured on the same device in one sitting. The point of assembling it is that the sources disagree in ways that are entirely explainable once you know what each one records.

Now line up the clocks, where the "installed" claim comes apart. The WUA history recorded success for KB5121003 at 5:37:57 PM. The Setup log recorded "a reboot is necessary before package KB5121003 can be changed to the Installed state" at 6:37:47 PM. The device sits at UTC+1 in August. Correct for the offset and those are the same moment, ten seconds apart.

The update agent stamped "installation succeeded" at the instant the servicing stack said the package could not reach the Installed state yet. Both are accurate, recording different events: the agent that its work was handed over and accepted, the stack that the transition was not finished. Every "installed but still offered" report I have chased lives in that gap.

The same offset shows up in DISM, and there it contradicts the documentation. The servicing stack update's InstallTime reads 5:25:28 PM; the Setup log records it reaching the Installed state at 6:25:28 PM. Identical seconds, exactly one hour apart, on a UTC+1 device. Microsoft's reference for that field says "this field is local time, based on the servicing host computer." Measured, it behaves as UTC. The cumulative update shows the same pattern: InstallTime 8:12:53 AM against a Setup event at 9:14:13 AM.

Finally, the Get-HotFix row for KB5121003 reads 8/20/2026 12:00:00 AM. The real transition was 9:14:13 AM. No time component, no state column — which is why four rows coexist with 415 packages on one machine, and why it can never answer an applicability question.

None of these sources is lying. They answer different questions: which build am I on, which package versions exist and in what state, does this package apply, what did the agent do, which CBS updates have history entries. The failure was only ever treating one answer as all five.

References

• DismPackageFeatureState enumeration — the eight documented package states with values, including DismStateSuperseded = 6 and its one-sentence definition.
• DismPackageInfo structure — where PackageState and Applicable are documented as separate members, plus InstallClient, InstallTime and SupportInformation.
• DismReleaseType enumeration and DismRestartType enumeration — the fifteen release types (note there is no servicing-stack type) and the three restart values including DismRestartPossible.
• Get-WindowsPackage — the -Online parameter, the basic versus detailed object, and the .msu limitation.
• IUpdateSearcher::Search — the full search-criteria table and the documented default, ( IsInstalled = 0 and IsHidden = 0 ).
• IUpdateSearcher::IncludePotentiallySupersededUpdates — the property that "is no longer supported in Windows 10, version 1709 (build 16299), and later OS releases."
• IUpdate — IsInstalled as evaluated "when the search is performed", and SupersededUpdateIDs, the collection of updates a given update supersedes.
• How Windows Update works — the scan terminology table defining detector updates and detectoids as IsInstalled applicability rules, and the Arbiter and action-list description of the install phase.
• Servicing stack updates — what the servicing stack is, and the combined SSU-plus-LCU payload since February 2021.
• August 11, 2026—KB5121003 (OS Builds 26200.9168 and 26100.9168) — the dual-build title, and "Includes KB5123304 (Build 26100.9156)".
• September 10, 2024—KB5043080 (OS Build 26100.1742) — the base 24H2 cumulative update still sitting in Staged, and the standard removal wording for a combined package.
• Win32_QuickFixEngineering class — the CBS-only scope and the duplicates remark behind Get-HotFix.
• Software updates maintenance (Configuration Manager) — supersedence rules, and the note that the waiting period "is based on the creation date of the superseding update".
• OperationResultCode — the enumeration behind the integer ResultCode in update history.