"Component Store Cleanup Recommended: Yes" - decide with evidence, and know what /ResetBase costs

DISM prints one line that splits every fleet in two: Component Store Cleanup Recommended : Yes. Half of us ignore it for three years. The other half wrap /StartComponentCleanup /ResetBase in a remediation script and push it to ten thousand devices on a Tuesday. Both groups are guessing, because almost nobody reads the word doing the work in Microsoft's definition of that field. The word is may.

Here is a decision framework instead. Every number came off one real corporate Windows 11 Enterprise device, 25H2, build 26200.9168, read-only, on 22 and 23 August 2026 — including the moment the automatic cleanup task ran, reported success, and reclaimed nothing at all.

The problem: "Cleanup Recommended: Yes" is a hint, not an instruction

Here is the real report from the lab device. Nothing was edited except trimming DISM's progress bar, which prints roughly a hundred lines of ASCII to say "working".

Four numbers, four meanings, and a fifth line recommending cleanup. Most people read the 24.81 GB, read the "Yes", and reach for the biggest hammer available. That reflex is the failure mode, because Microsoft's own definition of the field is deliberately hedged.

The second failure mode is worse: running /ResetBase across a fleet the week before a bad cumulative update lands. Microsoft states the consequence twice, on two pages. WinSxS cleanup guidance: "All existing update packages can't be uninstalled after this command is completed, but this won't block the uninstallation of future update packages." DISM reference: "Installed Windows updates can't be uninstalled after running /StartComponentCleanup with the /ResetBase option."

Why it happens: eight fields, hard links, and a task that did nothing

The eight report fields, decoded

The report has exactly eight fields and Microsoft documents every one of them. Here they are against what the lab device actually printed.

Why Explorer overstates by 2.01 GB

The gap between 24.81 and 22.80 is 2.01 GB, and it is not a bug. It is hard links counted more than once.

Microsoft: "there's usually only one copy of the file and the rest of the copies are actually hard links. Some tools, such as the File Explorer, determine the size of directories without taking into account that the contained files might be hard linked." A hard link is two directory entries pointing at one set of blocks. Explorer counts those blocks once per entry; DISM knows the difference.

Which makes the report's arithmetic checkable, and it checks out. Actual size minus shared-with-Windows is 22.80 minus 8.00, or 14.80 GB. Overhead is backups plus cache, or 14.79 GB plus zero. The 0.01 GB is rounding. Two independent paths to the same number is how you know you are reading it right.

Twenty-one reclaimable packages, one day after a successful cleanup

Now the part that makes the "Yes" confusing. The report says the last cleanup completed at 13:37:36 on 22 August, and that 21 packages are still reclaimable. Both are true, and the reason is documented.

Microsoft: "When run automatically, the task will wait at least 30 days after an updated component has been installed before uninstalling the previous versions of the component." That grace period is the whole point. It is the window in which you can still uninstall a bad KB.

The three newest updates here are KB5123304 (19 August), KB5121003 and KB5120708 (both 20 August). On 23 August they are three and four days old, so everything they superseded is deliberately still on disk. The package inventory measured on the same device shows the shape: 199 superseded, 121 installed, 95 staged. Superseded components are the raw material for both cleanup and rollback — the same bytes serving two purposes.

The run that reported success and reclaimed 1.3 MB

This is the part I did not expect to find. The automatic task really did run at 13:37 on 22 August. It really did return success. And it did essentially nothing, for a reason written plainly in CBS.log.

Read the sequence again. CSI compared a store coherency cookie against the cookie from the previous scavenge, found them identical, and skipped the work. CBS then stamped the run as complete, which is what set Date of Last Cleanup to 13:37:36.

So the report field is accurate and also misleading. A cleanup completed. Nothing was cleaned. And the 21 reclaimable packages would not have been touched even if the scavenge had run, because they sit inside the 30-day grace window.

Which binaries actually do this work

Worth knowing, because two of these are not where people assume they are. Every path and version below was read off the lab device.

The servicing stack is versioned separately from the OS: this device runs build 26200.9168 on stack 10.0.26100.9156, which is normal. That is why hardcoding a WinSxS path into a script loses. Read the path out of CBS.log instead.

How to verify: a decision path you can actually follow

Nine steps. Every one is read-only. Do not run a cleanup switch until you reach step 9, because steps 1 through 8 are the evidence that tells you which switch, if any, is correct.

1. Get the real numbers. Run Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore elevated and record all eight fields. If you only log one, log Backups and Disabled Features — the only field that represents recoverable space.
2. Compute overhead and sanity check it. Overhead is backups plus cache. Confirm it roughly equals actual size minus shared-with-Windows. Disagreement beyond rounding means a truncated or stale report.
3. Decide whether the number is worth acting on. Here it is 14.79 GB against 420 GB free: a monitoring note, not an incident. Cleanup earns its risk on constrained disks, not on principle.
4. Check the store is healthy first. /CheckHealth only reads a flag a previous failed operation set; /ScanHealth actually scans. Never clean up a store you have not confirmed is intact — you will delete the known-good versions a repair would have used.
5. Look at how old the newest updates are. If the most recent KB landed within 30 days, the automatic task will not remove what it superseded, by design. That is your answer to "why does it still recommend cleanup".
6. Ask whether you are inside a rollback window. This is the decision, and it is not a technical question. If a cumulative update landed this month and the fleet is not yet confirmed stable on it, those superseded versions are insurance you are still holding.
7. Check whether someone already spent it. Microsoft documents exactly one registry value for this, below.
8. Check whether the automatic task is completing. Read the task XML and its history before concluding maintenance is broken. On this device it is not broken; it is being interrupted.
9. Only now choose a switch — the scheduled task, /StartComponentCleanup, or /StartComponentCleanup /ResetBase.

Step 7: the one documented registry value

Microsoft's DISM reference gives exactly one tip here: "To determine when the /ResetBase option was last run, check the LastResetBase_UTC registry entry." Every value in the table shares this parent key.

Step 8: read the task, then read its history

Here is the real definition of the automatic cleanup task, exported read-only from the lab device.

Three settings in there decide whether your fleet ever finishes a cleanup.

ExecutionTimeLimit is PT1H — the documented timeout made visible: "If you choose to run this task, the task will have a 1 hour timeout and may not completely clean up all files." DisallowStartIfOnBatteries and StopIfGoingOnBatteries are both true, matching the documented default and the rule that maintenance runs only "when the machine is idle and on AC power". A laptop that lives on battery never cleans up.

Then the pair that matters most. StopOnIdleEnd is true and RestartOnIdle is false. Microsoft's rule is explicit: "To terminate and restart a task, both properties and elements must be set to True." Only one is. So the task terminates when the user comes back, and does not resume when the machine goes idle again.

The event log proof that this actually happens

All events below are from the channel Microsoft-Windows-TaskScheduler/Operational, which is enabled by default and held 16,915 records on this device. These are the real entries for the cleanup task.

Now put the two runs side by side. Within the log retention on this device, the cleanup task attempted twice.

Two attempts, two nights running. One terminated at six minutes because somebody touched the keyboard. One completed in fifteen seconds having deliberately skipped the work. Scale that to a laptop estate and the mystery of the permanent "Cleanup Recommended: Yes" evaporates.

The fix: what each switch buys and what /ResetBase costs

There are three routes, and they are not interchangeable. Microsoft's full syntax shows how they nest: /Cleanup-Image {... | /StartComponentCleanup [/ResetBase [/Defer]] | /AnalyzeComponentStore | ...}.

Read the /ResetBase cost precisely, because the precision is the point. It is not "you can never uninstall updates again" — future packages are unaffected. What you lose is the ability to uninstall everything currently installed, permanently, on that device.

So the cost is entirely a function of timing. Run it the day before a bad cumulative update ships and you have lost nothing. Run it the day after you deployed one and your rollback plan for that KB is gone, on every device the script touched.

The decision, stated plainly

Run nothing, and just monitor, when overhead is a small fraction of free space — 14.79 GB against 420 GB here. There is no case for spending risk.

Run the scheduled task when you want space back and want to keep every rollback option. It respects the 30-day window, which is exactly the protection you want mid patch cycle. Its weakness is the one-hour timeout and the idle interruption, so trigger it explicitly rather than hoping maintenance gets there.

Run /StartComponentCleanup without /ResetBase when a device is genuinely disk-constrained and needs more than the task will give. You skip the grace period but keep uninstall capability for installed updates.

Run /ResetBase in only two situations. On a reference image you are about to capture, where nothing has been in production so nothing is worth rolling back. Or on a specific device in a real disk emergency, where you have consciously decided free space now beats rollback later — and written that decision down.

Proof it worked: the evidence set to capture on both sides

I deliberately did not run /ResetBase here, so there are no after-numbers and I am not going to invent any. What I can give you is the measurement protocol and the real before-state. Capture these six things before you touch anything, and the same six afterwards.

Item 6 is the one nobody checks and the one that settles arguments. A cleanup reporting success with a zero-second scavenge did not clean anything, and re-running the task will not change that until the store itself changes.

After a real cleanup, success looks like this: Backups and Disabled Features is smaller, Number of Reclaimable Packages is lower, and CBS.log shows a scavenge with a non-zero duration and a meaningful used space change. If you ran /ResetBase, LastResetBase_UTC now exists — your permanent, machine-readable record that rollback for everything installed before that timestamp is gone.

And if Cleanup Recommended still says Yes afterwards, that is not a failure. It says overhead remains. On a device patched three days ago, protected by a 30-day grace period, that is the system working correctly.

References

• Determine the Actual Size of the WinSxS Folder - the /AnalyzeComponentStore command, the definitions of all eight report fields, and the overhead formula.
• Clean Up the WinSxS Folder - the StartComponentCleanup task path, the 30-day grace period, the 1-hour timeout, the /ResetBase uninstall warning, and the recommendation not to disable component cleanup.
• DISM Operating System Package Servicing Command-Line Options - the full /Cleanup-Image syntax, the /StartComponentCleanup and /ResetBase descriptions, the /Defer factory-only caveat, and the LastResetBase_UTC registry tip.
• Manage the Component Store - what the component store is for, including "Uninstalling problematic updates", and the hard link worked example.
• Automatic maintenance (Task Scheduler) - maintenance tasks run only when "idle and on AC power", task starvation, suspension on user return, and the rule that a completed attempt counts as successful even with a failure code.
• Task idle conditions - the definition of idle, the DisallowStartIfOnBatteries default, and the rule that StopOnIdleEnd and RestartOnIdle must both be true for a task to terminate and restart.
• MaintenanceSettings element - what Period and Deadline mean, and when the scheduler escalates to emergency Automatic maintenance.

All device values here were read from a single corporate Windows 11 Enterprise 25H2 device, build 26200.9168, servicing stack 10.0.26100.9156, on 22 and 23 August 2026. Every command shown is read-only, and no cleanup switch was executed — which is why there are no after-numbers. Validate against your own pilot ring before applying any of this to a fleet.