Rolling back a bad cumulative update: what is actually uninstallable, and how /ResetBase quietly took the option away

The ticket is always worded the same way. "The August patch broke the VPN client on 40 machines. Roll it back."

And the reflex is always the same too. Open an elevated prompt, type wusa /uninstall /kb:5121003, wait for the reboot, move on to the next fire.

That command has not done what you think it does for years. On a modern Windows 11 device it will not remove the cumulative update, and Microsoft says so in the KB article for the update you are trying to remove. Worse, the reason it fails is not a bug you can work around — it is a deliberate consequence of how updates have been packaged since February 2021.

And there is a second, quieter problem sitting behind it. Even the supported rollback route depends on files that Windows deletes on a schedule, and that an admin can delete permanently with a single command that most people run for disk-space reasons without reading the warning. If that command has run, the rollback you are about to attempt is not slow, or risky, or unsupported. It is impossible.

This post is about working out which of those situations you are in before you type anything. Every number in it was measured read-only on a live, corporate-managed Windows 11 25H2 device, build 26200.9168, three days after it took the August 2026 cumulative update.

The problem: "just uninstall the KB" is not a plan

A KB number is not a thing you can remove. That is the whole difficulty in one sentence.

A KB number is an article identifier. What actually lands on the device is a set of Component Based Servicing packages, and the mapping between the two is neither one-to-one nor obvious. On the lab device, Get-HotFix reports four entries. The package store reports 415.

That gap is not cosmetic. Get-HotFix wraps Win32_QuickFixEngineering, which returns only Component Based Servicing updates, and only some of those. If your rollback runbook starts by reading Get-HotFix, it is reading a summary of a summary.

Those three numbers are the whole story of this post. Installed is what is live. Staged is metadata present, payload not active. Superseded is the previous version of a component, kept on disk specifically so that a newer one can be backed out.

The 199 superseded packages are your rollback capability. They are also, exactly, the material that /ResetBase deletes.

Before you can act on any of that, you need to know which of three genuinely different rollbacks you are being asked for. They share no tooling.

Confusing row one with row three is the most common failure I see. Somebody runs DISM /Online /Get-OSUninstallWindow, gets an error, and concludes the cumulative update cannot be removed. Those are unrelated mechanisms with unrelated storage and unrelated expiry rules.

On the lab device, the August 2026 cumulative update is KB5121003, and the SSU it carries is KB5123304. Both appear in Get-HotFix as separate rows with separate install dates, which is the first visible clue that a single KB produced more than one package.

Why it happens: the combined package, the superseded set, and the 30-day clock

Take the two packages apart and the mechanism stops being abstract.

Read the identity left to right, because you will have to type it exactly later.

Now the part almost nobody looks at. Ask DISM for the detail view of each of those two packages and it tells you, in fields, exactly why one is removable and the other is not.

Four things in that output are worth putting on a wall.

The KB number lives in Description and SupportInformation. "Fix for KB5121003" and https://support.microsoft.com/help/5121003. This is how you get from a KB number in a change record to a package identity you can actually pass to DISM, without guessing.

SelfServicingPackage is the machine-readable flag for "this is the servicing stack". I checked all 121 installed packages on the device individually. Exactly one has SelfServicingPackage = True, and it is the SSU. That is a far better test than pattern-matching the package name.

Both halves report InstallClient: UpdateAgentLCU. They came in through the same delivery, from the same KB, as Microsoft documents. There is no separate SSU download to account for.

The install times differ by 14.8 hours. The SSU went in on 19 August at 17:25, the LCU on 20 August at 08:12. The servicing stack is installed first, and the machine then installs the cumulative update using the stack that just replaced itself. That ordering is the practical reason the SSU is not removable: you would be asking the current installer to uninstall the installer.

Where the revert material lives, and how long it lives there

Removing the LCU does not delete files and leave holes. It puts the previous version of every changed component back. Which means the previous version has to still be there.

Microsoft describes the lifecycle in one paragraph on the Clean Up the WinSxS Folder page: "Previous versions of some components are kept on the system for a period of time, allowing you to rollback if necessary. After a period of time, these older components are automatically removed from the installation."

"A period of time" has a number attached to it. The StartComponentCleanup scheduled task "will wait at least 30 days after an updated component has been installed before uninstalling the previous versions of the component." That task is enabled by default, runs during idle maintenance, and has a one-hour timeout.

So on any device you have not touched, your rollback window for a cumulative update is roughly 30 days from install, enforced by a background task, and it is not announced anywhere.

On the lab device that task is real and recently active.

That 15-second correlation matters more than it looks. It proves the "Date of Last Cleanup" field in the DISM report is written by the scheduled maintenance pass, not by an admin. Cleanup on this device is running on its own, yesterday, successfully.

And yet the device is still fully revertible. Two superseded RollupFix packages are still on disk. Automatic cleanup and /ResetBase are not the same operation, and conflating them is where people talk themselves into the destructive one.

What /ResetBase actually does to your options

Two Microsoft sentences, quoted exactly, are the entire payoff of this post.

From the Clean Up the WinSxS Folder page: using /ResetBase with /StartComponentCleanup "removes all superseded versions of every component in the component store." Followed immediately by a Warning block: "All existing update packages can't be uninstalled after this command is completed, but this won't block the uninstallation of future update packages."

From the DISM package-servicing options reference, in the /Cleanup-Image parameter table: "Installed Windows updates can't be uninstalled after running /StartComponentCleanup with the /ResetBase option."

Line those up against the census and the arithmetic is brutal. /ResetBase removes all superseded component versions. The device has 199 superseded packages. Those 199 are the "previous versions" that a cumulative-update uninstall reverts to. Remove them and there is nothing to revert to, so the uninstall is not slow or unsupported — it is gone.

The size figure makes it concrete. The real AnalyzeComponentStore run on this device reported an actual component store of 22.80 GB, of which 14.79 GB is "Backups and Disabled Features", with 21 reclaimable packages and "Component Store Cleanup Recommended: Yes". That 14.79 GB is the number that makes people reach for /ResetBase, and it is substantially the same material that makes rollback possible.

Read that warning precisely, though, because the scope is narrower than the panic suggests: "this won't block the uninstallation of future update packages." /ResetBase is not a permanent switch that disables rollback forever. It burns the updates that are already installed. Next month's LCU will be removable again, because it will create its own superseded set.

The binaries doing the work

Four files decide whether a rollback happens, and knowing which is which saves you from blaming the wrong one.

One measured oddity while you are in there. On this device the DISM command banner prints "Version: 10.0.26100.8972", the on-disk dism.exe reports file version 10.0.26100.8457, and the installed servicing stack package is ServicingStack_9156 at 26100.9156. Three different numbers, none of which equals another.

How to verify: eight checks before you type an uninstall command

Run these in order. Every one is read-only. By the end you will know whether the rollback is possible, which route to use, and how long you have — and you will not have destroyed the evidence you need if it turns out the update was innocent.

1. Establish what actually landed, from the package store and not from Get-HotFix. Get-WindowsPackage -Online is the ground truth. Group by PackageState and record the three counts. If the incident later turns out not to be the update, this census is the before-picture you will wish you had.

2. Turn the KB number into a package identity. Do not construct it by hand. Filter on the Description field, which contains the KB number verbatim.

3. Confirm you are aiming at the LCU and not the SSU. The SelfServicingPackage flag settles it. One package in 121 on this device carries it, and that package is the servicing stack. If your filter returns the SSU, there is no supported removal and no workaround to hunt for.

4. Confirm the revert material still exists. Count the superseded packages, and specifically look for a superseded RollupFix at a lower revision than the installed one. On the lab device there are two, at 26100.8655.1.20 and 26100.8875.1.28. If the only RollupFix package on the device is the installed one, there is nothing behind it to fall back to.

5. Check whether /ResetBase has ever run. This is the single most valuable check in the list and almost nobody does it. Microsoft documents the marker directly, as a Tip in the /Cleanup-Image section: "To determine when the /ResetBase option was last run, check the LastResetBase_UTC registry entry under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing registry path."

There is a second key worth knowing about, and a second trap in it.

6. Check the feature-update window separately, and expect it to be closed. This is a different mechanism with a different store: the old OS in Windows.old.

Error 1168 is ERROR_NOT_FOUND. There is no uninstall window to report because there is nothing to roll back to. The device moved to 25H2 via the enablement package back in February; Windows.old is long gone.

Be careful how you cite 1168, though. The DISM OS uninstall page does mention ERROR_NOT_FOUND (1168), but in a completely different context: running /Initiate-OSUninstall a second time after it has already succeeded, where "the uninstall will continue to proceed once the PC restarts." Microsoft does not document 1168 as the response to /Get-OSUninstallWindow on a device without Windows.old. That mapping is my measurement, not a documented behaviour.

7. Work out how much time you have left. Two clocks run in parallel and they are unrelated. For the cumulative update it is roughly 30 days from install before the StartComponentCleanup task removes the previous component versions. For a feature update it is the configured uninstall window. On the lab device the LCU went in 3.15 days ago, so the quality-update clock has plenty left; the feature-update clock expired months ago.

8. Confirm WinRE exists before you need it. If the update has left the machine unable to boot, the in-OS routes are all irrelevant. Check now, on a healthy device, that the recovery environment is actually present and enabled.

That version match is not decoration. The WinRE technical reference states that "The on-disk copy of Windows RE can be serviced as part of rollup updates for the OS. Not all rollup updates will service Windows RE." Here it clearly was, which is worth knowing: if the LCU you are about to remove also refreshed the recovery image, your recovery environment is not a pristine pre-update artefact.

Event ID catalog: the Setup log, WUSA provider

Both attempted and successful uninstalls write to the Setup event log. The provider is Microsoft-Windows-WUSA, and Microsoft does not publish an event-ID catalog for it — but the provider manifest is on every device, and it is authoritative. Here it is, read straight off the machine.

The channel is the Setup log. The full declared set:

Worth reporting the negative result honestly: on the lab device that filter returns nothing at all. No events were found matching the criteria, because wusa.exe has never been used on this machine. The catalog above comes from the provider manifest, which is Microsoft-authored and present regardless, not from observed entries.

For contrast, the Setup log is busy — the last 300 entries are 171 x Microsoft-Windows-Servicing Event 2, 124 x Event 1, 3 x Event 4 ("A reboot is necessary before package can be changed to the Installed state"), and one 1013/1014 corruption-detect pair. All servicing provider, no WUSA provider. Two different providers, one log.

The fix: the four supported routes, in the order you should try them

Now that you know what you are dealing with, here are the routes Microsoft actually supports, plus an explicit list of the ones it does not.

Route 1: DISM /Remove-Package against the LCU package name

This is the documented route, and Microsoft spells it out in the KB article for every combined update: "To remove the LCU after installing the combined SSU and LCU package, use the DISM/Remove-Package command line option with the LCU package name as the argument. You can find the package name by using this command: DISM /online /get-packages."

Three documented constraints will bite you if you skip them.

Only .cab can be named by path. Both the DISM reference and the Remove-WindowsPackage cmdlet documentation say it identically: "Removes a specified .cab file package from the image. Only .cab files can be specified. You cannot use this command to remove .msu files." Since what you downloaded from the catalog is an .msu, /PackagePath is not the parameter you want. Use /PackageName with the identity from the image.

/PackageName means "name as listed in the image". Not the KB number, not the file name, not a wildcard. The exact five-segment identity, tildes and all. This is why step 2 of the verification matters — you derive it, you do not type it from memory.

Offline removal does not shrink the image. "Using this command to remove a package from an offline image will not reduce the image size." If you are removing a package from a mounted WIM to fix a golden image, do not expect the file to get smaller.

Route 2: the Settings UI, when you have one machine and a user watching

Start > Settings > Windows Update > Update history > Uninstall updates. Same mechanism underneath, no typing, and it only lists what is genuinely removable — which makes it a fast eligibility check in itself. Microsoft's own how to uninstall a Windows Update page carries the blunt caveat: "Some updates cannot be uninstalled."

If the LCU you want is not in that list, that is a real answer. It means either the superseded material is gone or you are looking at a package that was never removable.

Route 3: WinRE, when the machine will not boot

This is the route people forget exists until 2 a.m. If the update left the device unable to start, none of the in-OS commands are reachable, and Windows will very often have taken you here already without being asked.

The recovery environment fails over automatically after: two consecutive failed attempts to start Windows; two consecutive unexpected shutdowns within two minutes of boot completion; two consecutive system reboots within two minutes of boot completion; a Secure Boot error (except issues related to Bootmgr.efi); or a BitLocker error on touch-only devices.

Once there, the path is Troubleshoot > Advanced options > Uninstall Updates, which offers Uninstall latest quality update and Uninstall latest feature update. Try the quality update first — it is the smaller, more likely change — then the feature update if the problem persists.

There is also a command-line option specifically for the did-not-boot case, and it is worth knowing the exact scope of it. From the DISM /Cleanup-Image parameter table:

Note also what /RevertPendingActions does and does not do. It reverts pending servicing actions — work that was queued and did not complete. It is not a general "uninstall last month's patch" command. For an update that installed cleanly and then caused a functional regression, Route 1 or the WinRE Uninstall Updates menu is what you want.

Route 4: feature updates, and the window you have to set in advance

Feature-update rollback is a completely separate subsystem with its own DISM verbs, its own storage, and its own expiry.

The documentation attaches a warning to /Set-OSUninstallWindow that is worth reading twice: "If days elapsed since installation is greater than this value, you cannot go back to the old version of Windows."

At fleet scale you set this by policy, not per device. The Update Policy CSP exposes it as ConfigureFeatureUpdateUninstallPeriod at ./Device/Vendor/MSFT/Policy/Config/Update/ConfigureFeatureUpdateUninstallPeriod, format int, allowed range 2–60, default 10 — which lines up exactly with the DISM command-line default and range.

Intune surfaces the same setting in update rings as "Set feature update uninstall period (2 - 60 days)", and its documentation gives the clearest description of the underlying mechanic I have found anywhere: "Configure a time after which feature updates can't be uninstalled. After this period expires, the previous update bits are removed from the device, and it can no longer uninstall to a previous update version."

Then a worked example that is genuinely instructive: "consider an update ring with a feature update uninstall period of 20 days. After 25 days, you decide to roll back the latest feature update and use the Uninstall option. Devices that installed the feature update over 20 days ago can't uninstall it as they've removed the necessary bits as part of their maintenance. However, devices that only installed the feature update up to 19 days ago can uninstall the update if they successfully check in to receive the uninstall command before exceeding the 20-day uninstall period."

Note the shape of that: it is the same pattern as /ResetBase. The rollback material has a lifetime, maintenance removes it, and the removal is not reversible. The only difference is that for feature updates you get a knob to lengthen the lifetime, and for cumulative updates you do not.

What is not a route

wusa.exe /uninstall /kb:<number> on a combined package. Microsoft states it will not work, and gives the reason. The switch still exists — the WUSA description page still lists /uninstall and /kb in its switch table with no deprecation notice — which is precisely why people keep reaching for it. Expect Setup Event 8, with the error code and your exact command line in the message.

wusa /uninstall /quiet in a script. The quiet uninstall path is widely reported to have been withdrawn deliberately, on the grounds that a silent background uninstall of a security update is itself an attack primitive, with the failure surfacing as Setup Event 8. Be honest about the sourcing here: I could not find that rationale stated on Microsoft Learn or support.microsoft.com. The clearest write-ups are community and MVP posts on Microsoft's own community hub, which is not the same as documentation. What is Microsoft-authored is the Event 8 template, which is on every device in the WUSA provider manifest, and the KB statement that the combined-package uninstall will not work. Plan around the documented facts.

Deleting anything from WinSxS. "Deleting files from the WinSxS folder or deleting the entire WinSxS folder may severely damage your system so that your PC might not boot and make it impossible to update."

Registry hacks to preserve uninstallability. Covered above. DisableResetbase and friends are undocumented; the documented middle path is /StartComponentCleanup without /ResetBase.

Proof it worked: the measured state of one real device

Everything above resolves to a single question per machine: can this device still roll back, and for how long? Here is that question answered for one real corporate laptop, on 23 August 2026, entirely read-only.

Verdict for this device, in one line: a bad cumulative update here is still removable via DISM /Remove-Package; the servicing stack inside it is not; and the feature-update window closed months ago. That is a defensible answer to give an incident manager, and every element of it came from a read-only check.

A few corroborating measurements, because they cross-check each other and one of them corrects a common assumption.

One footnote for anyone scripting against PackageState

The DismPackageFeatureState enumeration is documented with eight constants: DismStateNotPresent = 0, DismStateUninstallPending = 1, DismStateStaged = 2, DismStateRemoved = 3, DismStateInstalled = 4, DismStateInstallPending = 5, DismStateSuperseded = 6, DismStatePartiallyInstalled = 7.

The enum the PowerShell module actually exposes has nine names for those eight values.

The practical takeaway from all of it is smaller than the mechanism suggests. You do not need to memorise any of this. You need one read-only check added to the front of your rollback runbook — does LastResetBase_UTC exist, and are there superseded RollupFix packages behind the installed one — and one line added to your cleanup runbook recording when and where /ResetBase was run.

The devices that cannot be rolled back are not broken. Somebody decided, months earlier and for perfectly good reasons, to trade the option away for disk space. The only genuine failure is that nobody wrote it down.

References

• DISM Operating System Package (.cab or .msu) Servicing Command-Line Options — /Remove-Package and /Get-Packages syntax, the /Cleanup-Image parameter table including the /ResetBase and /RevertPendingActions statements, the LastResetBase_UTC tip, and checkpoint cumulative updates.
• Clean Up the WinSxS Folder — "removes all superseded versions of every component", the "can't be uninstalled after this command is completed" warning, the 30-day StartComponentCleanup grace period, and the do-not-delete-WinSxS warning.
• DISM Operating System uninstall Command-Line Options — /Get-OSUninstallWindow, /Initiate-OSUninstall, /Set-OSUninstallWindow, /Remove-OSUninstall, the 2–60 range with default 10, and the ERROR_NOT_FOUND (1168) note.
• Servicing stack updates — what an SSU is, and the February 2021 combined-payload change starting with KB4601382.
• Get-WindowsPackage (Dism) and Remove-WindowsPackage (Dism) — the PowerShell equivalents, and the ".cab only, not .msu" constraint.
• DismPackageFeatureState Enumeration — the documented eight package states and their numeric values.
• Update Policy CSP — ConfigureFeatureUpdateUninstallPeriod, its OMA-URI, allowed range 2–60 and default of 10.
• Update rings policy settings (Microsoft Intune) — "Set feature update uninstall period (2 - 60 days)" and the 20-day worked example, including "they've removed the necessary bits as part of their maintenance".
• Configure Windows feature update policies (Microsoft Intune) — "Feature update policies don't downgrade devices."
• Windows Recovery Environment (Windows RE) and WinRE troubleshooting features — automatic failover triggers, entry points, and the note that WinRE is serviced by rollup updates.
• How to uninstall a Windows Update — the Settings and WinRE paths, and "Some updates cannot be uninstalled."
• Description of the Windows Update Standalone Installer in Windows — the current WUSA switch table, which still lists /uninstall and /kb.
• Any monthly cumulative update KB article — the verbatim "To remove the LCU after installing the combined SSU and LCU package..." and "wusa.exe with the /uninstall switch on the combined package will not work" statements appear in the notes section of each one.

All device measurements in this post were taken read-only on a single corporate-managed Windows 11 Enterprise 25H2 device, build 26200.9168, servicing stack 10.0.26100.9156, on 23 August 2026. Console blocks are reproductions of real output, reformatted for width; no removal, cleanup or registry change was performed on the device. Values marked undocumented are exactly that — observed on one machine, with no Microsoft documentation behind them. Do not build policy on them.