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
PingBack from http://yeaa.info/?p=7318
Thanks for the additional inputs. I will definately update my http://www.winvistaclub.com/f16.html article and link back to this one :)
There is one more option to permanently remove the binaries for components that are not (and will never be) in use. It was described in the Server Core blog (http://blogs.technet.com/server_core/archive/2008/04/16/reducing-the-server-core-disk-footprint.aspx). So I guess it is also supported (thouh may be not recommended) action.
No wonder servicing is so slow and Windows needs to "configure updates". This has already become a nightmare for people who download 1 least one or two QFE/support hotfix, besides the monthly security updates.
And yes as long as Windows 7 inherits this change, I am going to stick with XP and eventually switch to non-Windows OSes. Software architecture/design should have some sensible balance between wasted disk space, impacted performance and reliability. I'm better off reinstalling Windows 2000/XP once maybe in 6 months due to an out of order uninstall and damaged files, I'm happy the way System File Protection works in pre-Vista OSes.
I have lots of questions regarding WinSxS but for now I would also like to know similar information about the DriverStore folder which is the next bloated "part" of the OS.
A commonly asked question among people looking at a Windows Vista or Windows Server 2008 installation
I have lots of questions regarding WinSxS but for now I would also like to know similar information about the DriverStore folder which is the next bloated "part" of Vista.
P.S.Please don't moderate this comment.
Hi Joseph, Thanks for the posting. It will be sure to get thousands of hits, since the 10 forum posting is long overdue to be summarized like this blog posting.
As a laptop user with a measley 30GB hard drive, this design really hurts me, WinSxs taking about 5GB, or 16% of my storage, on Vista x86, and getting worse as Windows Update pushes out more GDRs.
Has the Windows product group looked into improvements to help with the size requirements? Is this a concern which is on their radar? It seems to be causing dissat with so many of us customers with two year old hardware, since Microsoft of course wants us to keep the latest patches installed, we can't help the ballooning size of WinSxS, since there is absolutely no workaround except uninstall apps. One could argue, what's the point of an OS without the business apps on top.
Few suggestions we could hope for:
1. auto compress these folders. Seems like compression on these folders is not suggested and is against the rules?
2. do a differential of the files in these folders to reduce the footprint, rather than save the whole file.
3. Store these redundant files in a central repository on windows update, and let us all delete the local copies, and choose to download them only on demand should I need to uninstall/change my Windows components. If Windows Update installed them the first time, Windows Update should install them the second time only when needed.
4. Upon hitting low disk space - prompt user to automatically run VSP1CLN.EXE as part of disk cleanup utility. I saved quite a bit of space running that, but still WinSxs is almost 5 GB.
I do have a couple of question
- Since the largest folders (about 500 MB sum) are part of naturallanguage - how to remove natural language from Windows? I don't really need a speech reader if that's what it is
- Also other large folders are media samples from what I see on the net. This is concerning as well - why do we need to keep extra copies of samples of videos and such. This is sure to be a design oversight/bug? See screenshots at
Thanks again for your posting, Jason
I would also like to know similar info on why the DriverStore folder is so large.
Could you please describe what does a component's name mean?
Say I have a package named "amd64_microsoft-windows-timedate_31bf3856ad364e35_6.0.6000.20668_none_ea3547009847e745" (Just took a random update).
I understand what "amd64", "microsoft-windows-timedate" and "6.0.6000.20668" mean. But what is "none" and two hex strings (31bf3856ad364e35 and ea3547009847e745)?
thanks in advance
I have a VM setup with Windows Server 2008 x64. Server 2008 RTMed with SP1 but didn't include VSP1CLN.EXE. Why?
There's a way to move this folder or the only choice besides looking to prune the past versions is using a utility like Partition Magic or GPartED to resize the partition?
I have a W2008server with a 70GB OS disk. Installed hyper-v, SCVMM (beta). And know my disk is full, winsxs uses 57GB!!!!!!!! Not good.
Why can't it be in .cab or .wim file? Why it has to carry the 10MB junk in registry (HKLM\COMPONENTS)?
I'm sure Windows Update is so slow on Vista mainly because of it trying just open that ridiculously large directory!
The Vista servicing stack is non-friendly to the extreme, any kind of manual repair is impossible... Crypic XML files, cryptic directory names, cryptic registry entries... no chance of manual fixing at all.
Why can't it be like before? Because of delta-updating? Is it worth it? Why can't old scheme "copy-this-new-RTM|SP?GDR|QFE-file-and-backup-old-one work? I don't believe there were much problems with it.
Why it has to be so complex? Why TrustedInstaller has to spent all CPU managing those perverted directories, access rights and registry keys?
Only extremely brave people with a lot of free time can enter this dark ground; only Nuhi did WinSuxS cleanup with vLite afaik.
I have read the explanation and can only say that this file and its companion System32 are the best advertisements I have ever seen for Linux and Mac OS. If MS had any common sense or consideration for users they would withdraw this turkey and refund evry cent in the hope of stemming the flood to other OS
There are times when the Windows shell gives you incorrect information - not because it likes lying,