120 GB Freed on a Windows 11 Laptop by Clearing WinSxS With DISM

A 120 GB Windows 11 cleanup can include DISM, but WinSxS is usually only a small slice. Windows.old, `hiberfil.sys`, Delivery Optimization, old driver packages, restore points, and ISO downloads often explain the larger number.

120 GB Freed on a Windows 11 Laptop by Clearing WinSxS With DISM

DISM’s actual share of a large cleanup

DISM component cleanup acts on the Windows component store, the WinSxS folder that servicing uses so Windows remains repairable and updateable. A claim of 120 GB recovered from a Windows 11 machine needs category lines before WinSxS gets credited. On a typical desktop or laptop install, component-store cleanup usually returns a single-digit number of gigabytes. Even a heavily updated system rarely gives back more than 10 to 12 GB from WinSxS alone. Previous Windows installations, the hibernation file, cached update payloads, stale driver packages, restore points, and forgotten ISO downloads usually account for the larger total.

File Explorer can make WinSxS look larger than its real on-disk cost. A Windows 11 install may show 8 to 15 GB for that folder, because hard links cause the same underlying file to appear through more than one path. DISM reports the actual footprint with Dism /Online /Cleanup-Image /AnalyzeComponentStore, separating the apparent folder size from the space that can genuinely be reclaimed.

Microsoft documents Dism /Online /Cleanup-Image /StartComponentCleanup for shrinking the component store. The command does not remove Windows.old, turn off hibernation, clear the Delivery Optimization cache, prune old driver packages, delete restore points, or search a Downloads folder for ISO files.

Open Settings, then System, then Storage. Storage Sense groups used space into categories such as temporary files, previous installations, update caches, apps, documents, and system files. Those categories show why a three-digit recovery figure cannot be assigned to a single folder without measuring the rest of the drive.

Manual deletion inside WinSxS is a servicing-stack failure waiting to happen. The folder contains component payloads and hard-linked files referenced elsewhere in the Windows tree. Removing files by hand can break links that Windows servicing expects to find.

What /ResetBase removes

Run Dism /Online /Cleanup-Image /StartComponentCleanup /ResetBase from an elevated Command Prompt and Windows removes superseded versions of updated components. Those older component versions are the source of the normal rollback path for uninstalling an individual update. After /ResetBase, updates installed before the reset no longer have that path.

The space returned is the trade for surrendering those older versions. A machine that has run cleanly for weeks after patching has had time to reveal ordinary update trouble. A system only a day or two past a cumulative update has had much less time to expose a bad patch, so the same reset carries more risk. The effect is permanent for updates already installed when the command runs.

AnalyzeComponentStore includes a line reading Component Store Cleanup Recommended, followed by Yes or No. A No usually means the reset will return very little space while still removing rollback capacity for whatever superseded components exist.

The same output explains the misleading Explorer total. Explorer might report 11 GB for the folder while DISM reports an actual size closer to 7 GB, with shared hard links making up the difference. The reclaimable portion follows the DISM figure, not the Explorer folder total.

A cleanup that returns only a few gigabytes can still be operating exactly as designed. The rest of a large recovery comes from Windows features and user files outside the component store.

Hibernation can dwarf the WinSxS gain

On a laptop with 32 GB of RAM, hiberfil.sys can occupy 24 GB or more, because Windows sizes the file as a fraction of installed memory. If the machine relies on Fast Startup and the user never actually hibernates, powercfg /hibernate off deletes the file outright, and that single change can free more space than the full DISM cleanup on a high-memory system.

Delivery Optimization and old driver packages

Windows 11 caches update files it downloads. It also keeps update payloads for Delivery Optimization, the peer-to-peer distribution feature that shares update data with other machines on the local network. DISM component commands leave that cache alone.

Storage Sense lists the cache as Delivery Optimization Files. Disk Cleanup shows the same category after system cleanup options are enabled. A machine that has pulled several feature updates can hold a few gigabytes there before Windows trims the cache on its own.

Vendor driver updates delivered through Windows Update or vendor installers leave earlier packages behind in the DriverStore under OEM names. After several years, a graphics driver from a single vendor can leave a dozen stale copies stacked up.

pnputil /enum-drivers lists third-party driver packages with the published name, original name, provider, class, and version. Duplicate versions become easier to spot once the list is filtered or sorted by provider and original driver name. A specific old package can be removed with pnputil /delete-driver oemNN.inf, where oemNN.inf is the published name shown in the enumeration.

Built-in cleanup tools do not automate this pruning. The recoverable space depends on manual inspection: which packages are old copies and which packages are still bound to hardware.

Delete an active driver package and the device can fall back to a generic Microsoft driver on the next reboot. Network cards, touchpads, graphics devices, and storage controllers are the dangerous cases, because a bad deletion makes the next repair step harder. Check the enumeration output for packages currently bound to hardware and treat only unbound duplicates as removal candidates. The /force flag raises the stakes, since it can remove a package Windows would otherwise keep in place.

Windows.old and the ten-day rollback window

After a Windows 11 feature update or version upgrade, Windows keeps the previous installation in Windows.old at the root of the system drive. Settings, under System then Recovery, uses that folder to offer Go back for a limited period. On current builds, the window is ten days, after which Windows deletes the folder on its own.

The folder is often the single largest recoverable item. A major version upgrade can leave 20 GB or more in Windows.old. Disk Cleanup, in Clean up system files mode, exposes it as Previous Windows installation(s), and Storage Sense lists the same category. Removing it immediately returns the space and permanently removes the source files that Go back depends on.

A sequence that keeps the categories separate

Start with Dism /Online /Cleanup-Image /AnalyzeComponentStore so the WinSxS portion is measured before any reset changes it. Use Storage Sense or Disk Cleanup for Windows.old and Delivery Optimization, since those categories are built into the graphical cleanup tools. Hibernation belongs to powercfg, and only when the machine genuinely does not need hibernate behavior.

Driver packages come last because they require manual review that the other cleanup categories do not. The enumeration must show whether a package is still bound to hardware before it becomes a removal candidate.

Which entries are only old copies, and which entries are still serving a device?