The Windows Servicing Guy

Tips and tricks from a Windows support engineer on issues related to servicing

Should you delete files in the \WinSXS directory? And what’s the deal with VSS?

Should you delete files in the \WinSXS directory? And what’s the deal with VSS?

  • Comments 173
  • Likes

 

I like to read about how Windows is affecting peoples lives, specifically, the servicing components.  One of the common threads I noticed in my recent web trolling was the question “Can I delete the \Windows\Winsxs directory to save space?”.  This is usually asked in conjunction with what the directory does and why its consumed the space it has, but I’ve already covered that in prior posts.

So, to answer the question, the answer is simply: No.

Why?  Because the component store (\Winsxs) is needed to repair the OS binaries in the event that a file becomes corrupted or, in worst case scenarios, compromised.  There are a few directories in the component store so let’s look at them and what their general role is in Windows.

  1. \Winsxs\Catalogs:  Contains security catalogs for each manifest on the system
  2. \Winsxs\InstallTemp: Temporary location for install events
  3. \Winsxs\Manifests: Component manifest for a specific component, used during operations to make sure files end up where they should
  4. \Winsxs\Temp: Temp directory used for various operations, you’ll find pending renames here
  5. \Winsxs\Backup: Backups of the manifest files in case the copy in \Winsxs\Manifests becomes corrupted
  6. \Winsxs\Filemaps: File system mapping to a file location
  7. \Winsxs\<big_long_file_name>: The payload of the specific component, typically you will see the binaries here.

So, can you delete these?  Sure, you could I guess.  What would happen?  Well, it depends.  So long as the files in the \Windows\System32 directory are valid, most likely you wouldnt see any problems initially, the machine would “most likely” operate properly.  However, the first time you attempt to update a binary, apply a service pack or service a component, it’s going to fail because the backing components needed arent there.  The way the files end up in \System32 are via hardlinks.  This should help answer another common question I see regarding how VSS is used in servicing.  Short answer: It’s not.  We use NTFS hardlinks to project the file to the file system from the component store.  That’s why the \Winsxs directory is so important.  The files there can be seen as the “authoritative” versions on the file system.  When you encounter an issue and that binary needs to be replaced, running an SFC /SCANFILE against it will check the directories above and if the version doesnt match, it will re-project it so that its working.

Here’s an example of how you can see the hardlink via CLI:

C:\Windows\System32\drivers>fsutil hardlink list ntfs.sys
\Windows\System32\drivers\ntfs.sys
\Windows\winsxs\amd64_microsoft-windows-ntfs_31bf3856ad364e35_6.1.7600.16385_none_02661b64369ca03a\ntfs.sys

This isnt the best overall example but its one I use often as a quick and dirty way to see the links in the OS.  You can see that the NTFS file has a link to the \Winsxs directory and if that version of NTFS were to become corrupted, we could go back to the component store and find you a new copy.  The backup directory in \Winsxs is there in the event that the version in that directory has also become corrupted.  It’s a good way of having protection on the OS without consuming a huge amount of space. 

Also, as Andre mentions in the comment below, its worth noting that the new servicing structure does remove the $NTUninstall$ folders that many people have become accustomed to from Windows NT to Windows 2003.  Updates, if they are marked removable, no longer contain that structure.  Instead, updates are recommended to be removed via the Control Panel --> Programs  --> View Installed Updates path.  You can remove the updates via the appropriate switches in DISM.EXE or PKGMGR.EXE, but the control panel method tends to be cleaner.

Hope that helps.

--Joseph

Comments
  • You should also explain that the WinSxS folder replaces the old $NTUninstall folders from XP. So that the people understand better that it grows after installing Updates.

  • Thanks Andre, I've added an update.  I appreciate the comment.

  • But the very core design of the servicing stack is what users don't like. It should be engineered to take this much disk space. The servicing stack is the stumbling block when it comes to putting Windows 7 on small powered devices, slates and tablets. The user should always be able to decide whether he wants to back up files before an update and there should not be so intensive I/O involved in servicng (XP's servicing was so simple). It should not hog logon and logoff ("Please wait while Windows configures updates.." crap) but do all its work in the background. I hope it's completely rewritten in the next major release so that it's engineering for least I/O, least amount of disk space and no slowdown of logoff and logon. Hope this feedback goes loud and clear to the concerned people.

  • In my comment above, I meant "It should NOT be engineered to take this much disk space."

  • Thanks for the comments Pete.

    I understand what you're saying but I will disagree with you in that its the servicing mechanisms keeping Windows from smaller form factor devices.  While it might be a small portion of the portability problem to those form factors, the very existence of the servicing mechanisms is what makes porting to different classes of devices easier in the long run for us.  Because we're componentized we have the ability to generate new SKUs more readily than we did in the past.  

    From an I/O perspective, the servicing mechanisms arent much different than it was in XP.  We still have a pendingfilerename type operation that happens on boot, just like we did in XP, its just that you now have an indicator telling you that it happens rather than not.  The file copy on boot is still about the same.

    However, all that being said, I can tell you that this feedback is given directly to the product teams and they take the feedback seriously.  What that means for future products I'm not at liberty to tell you, but this does get to their ears, so feel free to keep it coming.

  • Hi Jascon.  I read the rationalizations for the ever growing winsxs directory and I'm afraid I am a bit angered by them.  (I'm not "shooting the messenger"!  Really!) .  My win7 winsxs, not very old, is >7GB.  Because this was an upgraded machine with smaller original partitions, I'm down to 1GB space and this is after using gparted to resize my disks once before.  (I won't get into the problem of ever growing virtual machines)

    When a program has a memory leak, it is fixed as a Severity 1 issue.  This is a storage leak, and  it is worse than your basic memory leak because it is permanent and designed with the knowledge that it will eventually take down the system and/or require major data movement and application reconfiguration.

    In 33 years of computing, I have never backed out a patch to an OS and on my personal PCs, I have no plans to start.  Thats what I have backups for.   The 1st thing I always did after applying maintenance on my personal machines was run ccleaner and wipe out the backups.  No going back, but I can, and want to live with that.  So the question, as asked before, is why am I forced to give up 7GB+ of space, and more for the future, for essentially no benefit?  You mentioned in another post a program to mark Vista SP1 updates as permanent and clean out the never-to-be-used clutter.  Does such a tool exist in a generalized form?   Can one be made?  (by the way, I have no idea what "multi-point servicing" is, a Google search turned up nothing, so I still don't understand why I might get 8 copies of a whole component for a fix that changed a single line of code). Thanks-- sorry for the rant, but I'm off to repartition this box again now.

  • Doug,

    Your complaint is not uncommon, it's one of the reasons I started this blog in the first place, to gather information that we could use to make Windows better.  Now I know that I am going to say may sound like the company man here, but for the most part, I like the way servicing is done in the OS now versus what we did in 2003 and earlier.  For me, its mostly because I get to deal with the aftermath, good or bad, of a servicing operation failures for the OS.  I cant tell you how many calls we used to get in NT-2000-2003 about someone applying a patch and a single binary failing to install bringing a server down.  For certain files, the only recourse was a rebuild because of the way the files had to "marry" together.  Add to that problems with recovery console, updates failing because of catalog issues, etc, and all in all, I think we're on the right track with what we're doing.

    Now thats not to say that the new servicing mechanisms are perfect, they arent.  I do know that a lot of the current mechanisms are in place because the storage issues of the past arent as relevant as they are today.  I know that certain configurations still have issues, but overall, its not the same problem as in the past.  Additionally, the new issues tend to be harder to troubleshoot because in the old days it was easier to just replace a binary and be done with it for a lot of cases (as long as you knew the binary).

    However with suggestions like those that we get here, we're looking at ways of making things better.  Developers on the teams read this blog and its comments for ways to make Windows better for everyone, so dont feel the need to not "shoot the messenger".  By contrast, fire away!  It's how things are made better and I welcome the chance to be that sounding board for you all.

    --Joseph

  • Should I mention for everyone a cool utility I found (very rare and probably one of its kind) that shws the actual size of any directory minus the special NTFS junction points (hard links, sym links etc). It's called cttruesize and can be downloaded here: www.heise.de/.../50272 Even with this utility and correct switches used, the size of WinSxS is unacceptable as a user. Hope this feedback goes to the Windows teams.

  • Are there parts of the component store that can be eliminated because they will never be used?  For example I have an Intel i5 based laptop, do I need all of the amd64_... directories in \WinSxS?  Is there some way to prune the directories for these unneeded components?

  • Jim;

    Thanks for the question, and its a good one.  The quick answer is no, you shouldnt delete the files that are there.  Do you need them all?  No, you probably dont but they are there in the event that you add a feature at some point that does require those files.  On the other hand, if you know you wont ever use a feature, you could, in theory, walk through all of the manifests for that feature and ensure that there arent any other components that rely on the components of that feature and then delete them to reclaim some space.  In the end, you'll find that its not really worth the effort I would imagine, but it can be done.

    --Joseph

  • Hi,

    You talked abt the difficulties in replacing the binaries in one of the comments above..

    How do we accomplish it in the newer OS, especially when the system does not boot or result in a endless time at applying/configuring updates.

  • Rahul,

    It depends on the situation.  If you're in a no-boot due to an update installation, you can always use the /revertpendingactions flag I speak about in another entry on here.  

    As for replacing system files, boot off of media and into WinRE and pull them from the DVD or another machine.

  • The WinSxS folder is consuming 35% of my total disk space - 23.2GB and this is by design? This is not acceptable! There should at least be a way for "Power Users" to disable this.

  • Somebody should also mention to the servicing team that, as big and inexpensive as my hard disk is, it does not mean that it is intended for the OS to crap all over.

  • 23.2GB is too large Neil, so in your case, I'd be interested to know where in \Winsxs that space is being consumed.  Typically your component store should be in the 8-12GB range with 12GB+ being a rarity.