Content is added to this directory in response to installing applications, enabling packages in the add-remove-programs UI, and installing Windows Out-of-Band releases. Content is removed from this directory as a result of uninstall + scavenging - a topic for another time. One important note - uninstalling your application or Windows app will not necessarily remove the physical bits from the system. The servicing stack marks the bits as unusable and prevents their use through "normal" means. Files and directories will be removed over time as the servicing system cleans up after itself. Administrators should not, for any reason, take it upon themselves to clean out the directory - doing so may prevent Windows Update and MSI from functioning properly afterwards. Preventing accidental deletion from the directory is accomplished by putting a strong security descriptor on the directory that inherits to its children.

In Windows Vista, the directory %windir%\\WinSxS has much stronger protection on it than it did in Windows XP and Server 2003. The owner/group is now a SID named "Trusted Installer", a service SID used to start the TrustedInstaller service. Users other than the trusted installer are granted only generic-read/generic-execute by default. This increased protection ensures that only the trusted installer service is allowed to modify the servicing-related metadata and files. If a limited user could modify a file in the directory, for example, they could convince the servicing stack to overwrite one binary with another when the next administrator comes along to enable the Games for Windows package.

You may or may not have ever peeked into the %windir%\\winsxs directory on your system. If you haven't, now would be a good time. First thing you'll notice is that there are a lot of those funkily-named directories. You might further notice that there seem to be several that differ only by what looks like a version number and some random-looking eight characters on the end of the name. Next you might see that some of them differ only by the second-to-last stringish thing. Lastly, note that mostly, the strings can be deciphered with a little help.

Each shared component (in the winsxs directory) gets its own directory into which its payload bits are placed. Somehow, we have to generate (mostly) unique & repeatable directory names for this purpose. The requirements of directory names are reasonably simple - can't overall be more than MAX_PATH (260) characters, can't contain certain characters, etc. Given the naming requirement, it was impossible to use the entire identity as the name of the directory, as someone could name their component "foo\\bar" and mess things up. With the extensibility requirement for identities themselves, we couldn't possibly use the entire identity, as the set of tuples would end up being far longer than MAX_PATH. Most importantly, we wanted the directory names to be readable to your average administrator or PSS representative. Finally, generation of the keyform from an identity had to be fast.

[http://blog.tiensivu.com/aaron/archives/ 1306-Demystifying-the-WinSxS-directory-in-Windows-XP,-Vista-and-Server-20032008.html]