Reduce Windows 7 WinSxS Folder Size

Originally published 23 June 2011 / Filed under Windows / Server

Archived note. Originally published 23 June 2011 on iishacks.com. It describes the Windows 7 component store as it behaved shortly after Service Pack 1 and is preserved here as a record. The command it recommends, dism /online /cleanup-image /spsuperseded, was later superseded by /StartComponentCleanup, and Windows 7 itself is long past end of support. Verify against current vendor documentation before applying any of it to a live system.

The original note

With Windows Vista, the WinSxS folder could be trimmed using a third-party tool (WinSxS Lite, Vista only). The initial release of Windows 7 removed that capability. Service Pack 1 brought an equivalent back, this time built into the servicing tooling itself.

The WinSxS folder stores install and uninstall files, Windows packages (current and previous versions of a component) and out-of-band releases. It should not be deleted.

Post-SP1, the unnecessary files can be removed from an elevated command prompt (Start → type cmd in Search → right-click cmd → Run as Administrator):

dism /online /cleanup-image /spsuperseded

This is useful for reducing the size of the Windows folder on SSDs and netbooks, where the system partition is small and every gigabyte is contested. In the case documented in the original note it recovered 3.5 GB.

What the component store actually is

Understanding why the folder grows is the difference between a safe cleanup and an unbootable machine. C:\Windows\WinSxS is not a cache and it is not a pile of leftovers. It is the component store: the authoritative copy of every servicing component Windows has installed, in every version it has installed.

Windows servicing is component-based. A feature, a driver package or an update is a component with a manifest, and the store holds the payload for each one. When an update supersedes a component, the older version is not immediately discarded, because Windows needs it in two situations: to uninstall the update and roll back to the previous state, and to repair the running system if a protected file is found to be corrupt or missing.

That is also why enabling an optional Windows feature usually needs no installation media. The payload is already in the store, and enabling the feature stages it into place.

Why it looks bigger than it is

Most of what lives under WinSxS is not a second copy of anything. The files that appear in C:\Windows\System32 and elsewhere are, in the general case, hard links to files in the component store: one set of data on disk, referenced from more than one directory entry.

Tools that walk a directory tree and add up file sizes cannot see that. Explorer’s properties dialog will happily report several gigabytes for a folder whose unique on-disk footprint is a fraction of that figure. The measured number is an upper bound, not a reading. Any cleanup decision made on the strength of that number alone starts from a distorted premise.

Why deleting it by hand breaks servicing

Deleting files out of the component store, or moving the folder to another volume and linking to it, is the most commonly attempted fix and the most reliably destructive one. The store is not addressed by path alone; it is indexed by manifests and by the servicing stack’s own metadata. Remove files behind the servicing stack’s back and the metadata still claims they exist.

The failure is usually not immediate, which is what makes it dangerous. The machine keeps running. The damage shows up later, at the next cumulative update or the next feature installation, as an update that fails to apply, a rollback that cannot complete, or a system file check that reports corruption it cannot repair. By then the cause is weeks in the past.

Because so many of those files are hard links, a manual deletion can also remove the payload that a live system directory is pointing at. Recovering from that generally means a repair install rather than a clever fix.

What /spsuperseded did, and what replaced it

dism /online /cleanup-image /spsuperseded removes the backup files that a service pack keeps so that it can be uninstalled. It is a one-way operation with a clearly stated trade: reclaim the space, lose the ability to remove that service pack. On a machine that has been running the service pack for months without incident, that is normally an acceptable trade. On a machine still inside a change window where a rollback might be needed, it is not.

Later Windows versions replaced it with a more general mechanism. dism /online /cleanup-image /startcomponentcleanup removes superseded component versions rather than service-pack backups specifically, and it is the supported command on Windows 8 and Windows Server 2012 and later:

dism /online /cleanup-image /startcomponentcleanup

Adding /ResetBase takes it further and removes every superseded version of every component in the store:

dism /online /cleanup-image /startcomponentcleanup /resetbase

That reclaims the most space and carries the largest consequence: after a reset base, the updates already installed can no longer be uninstalled individually. It is a reasonable step when preparing a golden image, and a poor one on a production server that may need a bad update backed out.

Newer versions also added an analysis command that reports the store’s actual size and whether a cleanup is recommended, which is a better basis for a decision than a folder-size reading:

dism /online /cleanup-image /analyzecomponentstore

On Windows 7 specifically, a later update surfaced an equivalent cleanup through the Disk Cleanup tool as a Windows Update Cleanup option, which is the same idea wrapped in a dialog. The full DISM syntax quoted above belongs to the later releases, not to the 2011 machine this note was written on. The current options are documented in Microsoft’s DISM operating system package servicing reference.

The same problem on Windows Server

Server installations hit this harder than desktops, because a server that has been patched monthly for several years accumulates more superseded component versions than a workstation that gets reimaged. The classic symptom is a system volume sized for the original build that quietly fills over a multi-year service life, on a machine whose partition layout cannot easily be changed.

Two things changed on the server side after the era of this note. The cleanup became a scheduled maintenance task rather than something an administrator had to remember, running under the servicing task set with a grace period before a superseded component is eligible for removal, and a time cap so that it cannot run indefinitely. And Features on Demand made it possible to remove a disabled feature’s payload from the store entirely, at the cost of needing installation media to add it back later.

The practical guidance that survives from 2011 is unchanged, and it is the part worth keeping: measure before acting, use the servicing stack rather than the file system, and understand which rollback you are giving up before you run the command. General servicing and platform documentation lives at Microsoft’s Windows Server documentation, and support dates for any version named on this page can be checked against the Microsoft product lifecycle.

Other notes from the same period are collected under Windows / Server. The disk-space pressure described here was, at the time, mostly an SSD problem, and the drives of that generation had failure modes of their own — see the note on an SSD freezing on Windows 7. A separate Windows 7 desktop-shell fault is recorded in the note on desktop icons and shortcuts disappearing. The full index of preserved notes is at post archives, and the archive front page is at IIS Hacks.