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.
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. ”
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:
- Uninstall applications (possible)
- Use the vsp1cln.exe tool after installing Windows Vista SP1
- Use the compcln.exe tool after installing Windows Vista SP2
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. 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