In last week’s TR Dojo Challenge question, I asked TechRepublic members how do you safely reduce the size of the WinSxS folder. Before we get to the solution, let’s get a little background on the Windows Side-by-side (WinSxS) folder.

Understanding Windows Side-by-side assemblies and the WinSxS folder

In an effort to combat the dynamically linked library (DLL) problems that plagued Windows 9x, Microsoft introduced the concept of Side-by-side (SxS) assemblies in Windows XP. DLL hell, as these problems were often referred to, occurred when multiple applications (let’s say App. 1 and App. 2) relied on a single .DLL file. If App. 1 updated the .DLL file to a new version, but App. 2 still needed the old version, App. 2 might no longer work.

.LOCAL isolation and WinSxS in Windows XP

Prior to Windows XP (but also supported by XP), developers could use a process called .LOCAL isolation to prevent DLL conflicts. In a nut shell, .LOCAL isolation meant that applications would first look in the application directory for all the associated .DLL, .OCX, and .EXE files. If Windows didn’t find the required file in the application directory, it would look for the file in other locations, such as the System32 directory. .LOCAL isolation could reduce DLL conflicts, but wasn’t without drawbacks. First, installing multiple copies of the same shared .DLL file wastes disk space. Second, if a security vulnerability was discovered in a specific .DLL file, you would need to update every copy of that file, instead of just a single shared file. Windows Side-by-side was designed to address these problems.

When Windows XP was released, many developers were still supporting applications that had to run on previous Windows versions. It took several years, and the proliferation of Windows XP, for most developers to embrace the new methodology. On Windows XP machines, the WinSxS folder is only created if the user installs an application that uses it.

WinSxS in Windows Vista and beyond

With the release of Windows Vista, Windows Server 2008, and now Windows 7, Microsoft significantly expanded the role of the WinSxS folder. Unfortunately, Microsoft seems to provide two different descriptions of the WinSxS folder.

In a September 17, 2008 post on Microsoft’s Ask the Core Team TechNet blog, Joseph Conway, Senior Support Escalation Engineer, described the WinSxS folder thusly:

“All of the components in the operating system are found in the WinSxS folder – in fact we call this location the component store.  Each component has a unique name that includes the version, language, and processor architecture that it was built for.  The WinSxS folder is the only location that the component is found on the system, all other instances of the files that you see on the system are “projected” by hard linking from the component store.  Let me repeat that last point – there is only one instance (or full data copy) of each version of each file in the OS, and that instance is located in the WinSxS folder. “

Yet in a November 29, 2008 post on Microsoft’s MSDN blog, Michael Beck gave the following definition:

“In practice, nearly every file in the WinSxS directory is a “hard link” to the physical files elsewhere on the system-meaning that the files are not actually in this directory. For instance in the WinSxS there might be a file called advapi32.dll that takes up >700K however what’s being reported is a hard link to the actual file that lives in the Windows\System32, and it will be counted twice (or more) when simply looking at the individual directories from Windows Explorer.”

Taking his explanation a step further, Beck explains that because of this hard linking, Windows Explorer may misreport the actual size of the WinSxS folder. According to Beck:

“The Windows SxS directory represents the “installation and servicing state” of all system components. But in reality it doesn’t actually consume as much disk space as it appears when using the built-in tools (DIR and Explorer) to measure disk space used. “

These descriptions seem to contradict each other. Conway asserts that the WinSxS folder is THE storage location for the files that Explorer reports it contains, which are then projected onto other locations. Beck seems to describe the WinSxS folder as containing mostly links (which Explorer treats as files) to physical files that actually exist in other directories. Luckily, this dichotomy has no impact on our efforts to reduce the size of the WinSxS folder.

Reducing the size of WinSxS

Regardless of whether the WinSxS directory is the physical repository for the actual component files or a collection of hard links to files stored across the drive, manually deleting files from this folder is a bad idea. Doing so could prevent applications from running and make the system unstable. So how do we reduce the size of the WinSxS folder–either as perceived by Explore or in actuality? There are three ways:

  1. Uninstall applications (possible)
  2. Use the vsp1cln.exe tool after installing Windows Vista SP1
  3. Use the compcln.exe tool after installing Windows Vista SP2

Uninstalling applications

Of the three methods I describe, I am least certain that this one will work. According to posts on Microsoft forums and around the Web, Windows Vista and later versions contain a “self scavenging” feature that will delete files from the WinSxS folder as they are replaced by newer versions or are no longer used. However, I have read just as many reports of the WinSxS folder remaining the same size even after users uninstalled applications or components. You’ll just have to take your chances with this method.

Use vsp1cln.exe to clean up after Windows Vista SP1

One method that does seem to work is removing the redundant files left over after installing Windows Vista SP1. Thankfully, Microsoft provides the Windows Vista SP1 Files Removal Tool (vsp1cln.exe), which does just that. The tool is automatically installed as part of the SP1 upgrade, and you can find it at \%windir%\system32\vsp1cln.exe. I describe how to use the vsp1cln.exe in the TR Dojo video, “Remove all remnants of the Windows Vista SP1 installation files”. Just make sure you’re sticking with SP1 before running the tool, as you can’t remove SP1 afterwards.

Use compcln.exe to clean up after Windows SP2

Just like cleaning up after SP1, you can use the Service Pack Clean-up tool (compcln.exe) to remove the files left over after installed Windows Vista SP2. Compcln.exe is an improved version of the earlier vsp1cln.exe tool. It is installed as part of the SP2 upgrade, and you’ll find it at \%windir%\system32\compcln.exe. As with vsp1cln.exe, running compcln.exe will prevent you from removing SP2.

And the TechRepublic swag goes to…

This week’s coffee mugs and laptop stickers to richardqt, who was first to mentioned vsp1cln.exe, and GreatZen, who provided an excellent description of the WinSxS folder, links to several relevant articles, and mentioned compcln.exe. Thanks to everyone who submitted an answer. If you don’t see your answer here, be sure to give this week’s question, “How do you prevent Windows from rebooting after an automatic update?” a try.

You can also sign up to receive the latest from the TR Dojo through one or more of the following methods:

For more information on the WinSxS folder, vsp1cln.exe and compcln.exe, check out the following resources: