Microsoft Enterprise Platforms Support: Windows Server Core Team
A commonly asked question among people looking at a Windows Vista or Windows Server 2008 installation is “why is the WinSxS folder so big?!” To answer that question I need to first describe componentization, and how components are managed in Windows Vista.
One of the largest changes between previous versions of Windows and Windows Vista was a move from an INF described OS to componentization. A component in Windows is one or more binaries, a catalog file, and an XML file that describes everything about how the files should be installed. From associated registry keys and services to what kind security permissions the files should have. Components are grouped into logical units, and these units are used to build the different Windows editions.
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. So looked at from that perspective, the WinSxS folder is really the entirety of the whole OS, referred to as a "flat" in down-level operating systems. This also accounts for why you will no longer be prompted for media when running operations such as System File Checker (SFC), or when installing additional features and roles.
That explains why the folder starts off big, but not why it gets larger over time – the answer to that question is servicing. In previous versions of Windows the atomic unit of servicing was the file, in Windows Vista it’s the component. When we update a particular binary we release a new version of the whole component, and that new version is stored alongside the original one in the component store. The higher version of the component is projected onto the system, but the older version in the store isn’t touched. The reason for that is the third part of why the component store gets so large.
Not every component in the component store is applicable, meaning that not every component should be projected onto the system. For example, on systems where IIS is available but has not been installed, the IIS components are present in the store, but not projected into any location on the system where they might be used. If you’re familiar with how multi-branch servicing works in previous versions of Windows then it’ll make sense to you that we have a different version of the component for each distribution branch and service pack level, and that all these different versions are also stored in the WinSxS folder, even if they’re not immediately applicable. So a single Post SP1 GDR package that contains an update to one component will end up installing four versions of that component in the WinSxS folder – double that on a 64 bit operating system for some components.
Now that you know why the store can grow to be so large, your next question is probably to ask why we don’t remove the older versions of the components. The short answer to that is reliability. The component store, along with other information on the system, allows us to determine at any given time what the best version of a component to project is. That means that if you uninstall a security update we can install the next highest version on the system – we no longer have an “out of order uninstall” problem. It also means that if you decide to install an optional feature, we don’t just choose the RTM version of the component, we’ll look to see what the highest available version on the system is. As each component on the system changes state that may in turn trigger changes in other components, and because the relationships between all the components are described on the system we can respond to those requirements in ways that we couldn’t in previous OS versions.
The only way to safely reduce the size of the WinSxS folder is to reduce the set of possible actions that the system can take – the easiest way to do that is to remove the packages that installed the components in the first place. This can be done by uninstalling superseded versions of packages that are on your system. Service Pack 1 contains a binary called VSP1CLN.EXE, a tool that will make the Service Pack package permanent (not removable) on your system, and remove the RTM versions of all superseded components. This can only be done because by making the Service Pack permanent we can guarantee that we won’t ever need the RTM versions.
So yes, the WinSXS folder is very large, and it will continue to grow as the OS ages. I hope that this clears up some of the questions about why that is, and what you can do about it. Note that the Windows servicing structure and the layout of the store is subject to change.
Joseph Conway Senior Support Escalation Engineer Microsoft Enterprise Platforms Support
Can I delete the contents? Yes/no. If no; can I delete some?
Since I pay for extra storage and the disk got full directly costing extra every month.
Thanks for the explanation-- very informative article.
I have found on net that windows 7 or later might not be having VSP1CLN.EXE file bundled in SPs.
use DIMS to reduce Service Pack files from winsxs folder, that reduce the size of folder by 3-4-6 GB depending on how inflated it already is.
DISM.exe /online /Cleanup-Image /spsuperseded
you can add /hidesp option to remove SP1 (KB976932) entry from the “Installed Updates” section of Programs and Features so that users do not try to uninstall the Service Pack.
www.happysysadm.com/.../clean-up-winsxs-on-windows-2008-r2.html
You can also delete content of winsxs/ManifestCache to save additional 1/2 GB or more space.
on elevated cmd, give
Net stop trustedinstaller
Takeown /f %windir%\winsxs\ManifestCache\*
Icacls %windir%\winsxs\ManifestCache\* /GRANT administrators:F
Del /q %windir%\winsxs\ManifestCache\*
--
answers.microsoft.com/.../3d83a43c-0af1-448f-8bda-8150ff201d2e
Thanks.
Rawat
INDIA
I use a reliable duplicate file checker and symbolic link utility which parses a selected point and downwards into the subdirectory and I found nothing but 4+GB of duplicate files and NO SYMBOLIC LINKS they way your article describes.
I verified it by renaming either the source files in WinSXS and monitoring the duplicate file (verified by MD5) and the "projected" file name never changed. If modifying the "projected file", the supposed source inside WinSXS also didnt' change.
If mounted offline in XP or Unbuntu, it was verfied these links you cliam to exist, arent for real.
What was for real, was the 2GB I carved out in less than 1 hour by deleting just the files 1MB= and larger and Vista Business till boots, just fine and annyingly aas it did before.
Dear Joseph, having understood now - thanks to you - how the new OS is organised, I would like to ask the following question which concerns the 64-bit version of Windows 7 SP1. My question originates from the fact that I could not install the new update for my ATI graphics card. The module concerned uses the library extension msvcrt.dll which works in conjunction with the "Microsoft Visual C++ 2010 x86 Redistributable" library.
In the WinSxS folder are stored 5 different versions of the mscvrt.dll, 4 of them are lately updated (installed) at the same date and time. One of the 4 versions is projected to the System32 and the same is projected to SysWOW64 folder. According to the version number this is not the newest. Since the same version is also used in my 32bit OS I presume that the projected version relates to my specific system architecture and the version number does not relate to a higher update level.
There is also a Backup folder in the WinSxS which holds the projected version for security reasons?
Can you tell me if my assumptions are true? Further more: Is it possible that the projected version of the msvcrt.dll in the SysWOW64 is incompatible with the ATI module written in Visual C++ 2010 because it returns Exception Code: c0000005?
Kind regards
Lutz Pansegrau
Cape Town
I used remove-windowsfeature -remove and the binary files revomed from the windows\winsxs folder. How I could bring back the binary file to this WinSxs folder.
I would rally like to meet all the geniuses responsible for this concept and have a little chat with them using baseball bat.
Stupid morons!
a fantastic light on a somewhat clouded folder , thanx
none of this is any help and I can barely even use my pc because of this crap, can do any updates or downloads nothing my pc is seconds away from crashing.
clean install os. install all updates and current version of programs. Imediately create backup from backup center. every month put that backup cd into tray. go to winsxs on your installed system, properties, previous versions and choose winsxs from first backup.
On a mission critial server, reinstalling the system or even taking it offline for an extended period of time is just not an option. Is there no tool available that can safely remove obsolete files from Winsxs?
In terms of Windows Administration, this is (hands down) the worst thing MS has done. A SysAdmin is now supposed to account for unknown growth rates that depend on how many patches/fixes have to be deployed. And there is no easy way to reduce the size.
From a Server Management standpoint, it's the biggest mistake I've ever seen out of MS b/c there is no way to work around it. You're at the complete mercy of whoever you replaced with few choices for correction. It's horrible.
This is a horrible engineering plan that should never have seen the light of day. If you just asked some System Admins or IT Managers "Hey, we're going to make Windows more stable by telling Windows to show tons of your disk as being full. It will continue to grow and grow and grow every time that Microsoft releases a patch. Does that sound good? But wait - we're also going to make it so that you can do almost nothing to reduce or control your size. You'll just have to rebuild your server if we give you a lot of Windows patches." Ask some actual IT people this question instead of deciding it on the golf course with a bunch of VP's and MS could have avoided this.
That teaches us to disable automatic update and just run sp lol
Here is the ultimate guide to recover your WinSXS space safely:
dandar3.blogspot.pt/.../how-to-ntfs-compress-windows-winsxs.html
I've seen results of space gains ranging from 6 GB to 11 GB!