WinSxS directory - what is it about

  • Thread starter Thread starter occam
  • Start date Start date
O

occam

I have just noticed this large(ish) directory under C:/Windows.

Is this new (i.e. post SP3) or has it always been there? What is its
function.

My searches show that it is an innovation for Vista. However, it is
definitely there in Win XP now, as a retro-fit?

The only consolation - its does not gobble up as much space as the 6GB
Vista equivalent.
 
I posted this to a Windows 2000 group a few weeks ago, it should answer
your questions.

Do you recall the term "DLL Hell"? The new(er) Side-by-Side Assembly
technology was introduced with Windows XP to help reduce or eliminate
DLL Hell. In short, Side-by-Side Assemblies permit the use of different
versions of the same shared system DLLs.

If you recall earlier Windows versions, like Windows 95, when you
installed an application you were (usually) warned if the installer
tried to replace a DLL from the system folder with an older version and
you were asked if you wanted to accept the change. Those with enough
Windows experience knew of the consequences of replacing DLLs in the
system folder with older ones, those who didn't have enough experience
quickly learned of the consequences of replacing DLLs with older versions!

With private DLLs there are few or no problems with DLL versioning as
private DLLs are placed in the program's folder. If you have different
versions or releases of the same program simply installing the different
versioned programs in different folder eliminates private DLL version
conflicts. Until Windows XP it wasn't so easy to use different versions
of shared system DLLs, that is what the new Side-by-Side assemblies
attempts to resolve.

This business of applications replacing system DLLs wily-nilly and the
DLL Hell that ensued was somewhat fixed with the Windows File Protection
feature (WFP) introduced with Windows 2000 but the shared DLL versioning
problem was not really fixed or properly addressed. Considering WFP and
the fact that WinSxS is a protected folder I am somewhat surprised that
you could "delete" this folder or manually delete/replace files in the
folder, on Windows XP and later WFP does not easily permit this.


Wikipedia's concise explanation of SxS is one of the better one:

"A common issue in previous versions of Windows was that users
frequently suffered from DLL hell, where more than one version of the
same Dynamically Linked Library (DLL) was installed on the computer. As
software relies on DLLs, using the wrong version could result in
non-functional applications, or worse. Windows XP solved this problem by
introducing side-by-side assemblies. The technology keeps multiple
versions of a DLL in the WinSxS folder and runs them on demand to the
appropriate application keeping applications isolated from each other
and not using common dependencies."

http://en.wikipedia.org/wiki/Featur...ication_isolation_.26_side-by-side_assemblies


The rest of this post consists of excerpts and explanations from
Microsoft articles:

Side-by-Side Sharing

The workings of the new (XP) UI rely on a side-by-side sharing
requirements structure. As a solution for versioning problems and DLL
Hell, Microsoft strongly suggests that applications adopt a side-by-side
versioning strategy. As seen in the implementation of ComCtl version 6,
side-by-side components are the future of Windows development. This
section gives you an overview about what's new for side-by-side sharing
for Windows XP. For an in-depth look into this topic, see How To Build
and Service Isolated Applications and Side-by-Side Assemblies for
Windows XP. For background on side-by-side component sharing issues and
DLL redirection, see Implementing Side-by-Side Component Sharing in
Applications (Expanded).

With side-by-side components, multiple versions of a component are
installed simultaneously. An application is bound to the version of the
component with which it was designed and tested.

With Windows XP, there's an infrastructure to support assemblies and
isolated applications (both COM+ and Win32). A code change should not be
required to get at side-by-side assemblies from Win32 applications.
Applications can use the latest system assemblies without global impact.

In short, isolated applications are valuable because they are more
reliable. They are built and shipped with all needed components and are
not affected by changes that other applications make. Isolated
applications use a manifest, which is an XML file containing information
that self-describes an assembly or an application. All binding and
activation metadata, such as COM classes, interfaces, and type
libraries, is now stored in the manifest, rather than the registry.
There are two types of manifest files: applications manifests, which
describe isolated applications, and assembly manifests, which describe
individual assemblies.

An isolated application may use side-by-side assemblies. Assemblies are
the fundamental units of naming, binding, versioning, deployment, and
configuration. They come in two varieties, shared and private. A shared
assembly is available for use by multiple applications on the computer,
installed in the WinSxS folder in the Windows directory. A private
assembly is only visible to that application and is deployed within the
directory structure of the application.

There's another benefit for application developers in using side-by-side
sharing; your schedule can be much clearer. Your development schedules
are not affected by the release schedules of the components you use.

[end quote]

http://msdn.microsoft.com/en-us/library/ms997638.aspx


Windows 2000 doesn't understand diddly squat of these new Side-by-Side
Assemblies, here are more passages from Microsoft articles:

"If you install your application on a computer that is running Microsoft
Windows 2000 or earlier versions of Windows, do not ship the
side-by-side assembly in your application folder to those operating
systems. Instead, the side-by side assemblies should be used from the
system folder. If you install a shared component to the system folder as
part of your setup, make sure that you are not downgrading the version
if one is previously present."

http://msdn.microsoft.com/en-us/library/ms997620.aspx

and:

"On versions of Windows that do not support deployment of shared
side-by-side assemblies, such as Windows 98 and Windows 2000 Server, the
Visual C++ libraries are installed in the System32 folder and WinSxS
folder under the operating system root directory. This setup enables
running Visual C++ applications on these operating system versions
because they do not support manifest-based binding of applications to
dependent DLLs. On these operating systems, when an application is
loaded, the corresponding manifest file is ignored and the operating
systems searches for dependent DLLs using paths set in the current
running environment. However, on upgrading the operating system to a
version that support manifest-based binding, such as Windows XP, Windows
Server 2003, or Windows Vista, applications built with manifests start
using the DLLs installed in the WinSxS folder."

http://msdn.microsoft.com/en-us/library/ms235624(VS.80).aspx

John
Click to expand...
 
I have a winsxs folder under C:\Windows, which is okay -- but I also another
one under E:\Windows, which is not okay. My E: drive is a physically
separate hot-swappable SATA drive, and it is not always in the computer. I
really need to move that winsxs folder off of the E: drive. Is there a way
to do that?
Thanks,
Raphael
 
What's preventing you from moving it? The Windows installation only
uses one SxS folder, the one in the current %systemroot% folder.

John
 
Hi John,

Thanks for your reply.

I am cautious about moving the SxS folder on E:, because whatever put that
folder on E: might also need to be able to find it there. To move that SxS
folder from E: to C: without risk, would not all references to it need to be
adjusted to reflect its new location?

Raphael
 
Why do you want to move it to the C:\ drive? This (C:) is presumably
your current system drive, the operating system does not use the SxS
folder on the E: drive, it uses (or should use) the one in the
C:\Windows folder. Try renaming the folder on the E: drive and use the
computer for a week or two and see if you have problems. The folder on
the E: drive is probably a backup of some sort.

John
 
Hi John,

Thanks for your reply.

Yes, C: is my computer's system drive.

The E: drive is not always in my computer, and I don't want to cause a
problem by having whatever program placed the SxS folder on E: then seek the
contents of that folder at a time when the E: drive is not present.

I will follow your renaming and give-it-a-try suggestion.

Yes, it seems likely that the SxS folder on E: is a backup. I say that
because its contents are identical with one small part of the contents of the
SxS folder on C:.

Raphael
 
Are there any problems when the E: drive is disconnected? You say that
the drive is not always in your computer, so when it isn't in the
computer what problems are you experiencing with the missing
E:\...\WinSxS folder? You can get yourself a copy of Filemon from
Microsoft's SysInternals and monitor the access to the SxS folder on the
E: drive and find out what, if anything, might be accessing or using the
folder. My guess is that the folder is only a backup.

John
 
Hi John,

The E:\...\WinSxS folder appeared only three days ago, and since then I have
not dared disconnect E:. I do not know whether there would be an SxS problem
if I did disconnect E:, and I do not want take to take the risk of causing a
problem if I do disconnect E:.

I appreciate the idea re Filemon, and will do as you suggest.

Raphael
 
I don't think that the SxS folder on E: would be used. The WinSxS
folder is a protected folder that can't be moved or deleted, attempting
to move or delete this folder simply causes Windows to almost
immediately reboot, after the reboot you will find the folder restored
to its original location.

John
 
The "reboot" possibility makes me very cautious about disconnecting E: --
i.e., what would happen if E: is not present when Windows tries to restore
the SxS folder to E:?

Raphael
 
I don't see Windows trying to restore this folder, I may be wrong but I
just don't think that this WinSxS folder on E: is even used, the proper
location for the Side-by-Side assemblies is in the %systemroot% folder,
the assemblies belong or reside at C:\Windows\WinSxS. If the folder is
not in that location certain applications and Windows components (like
Windows updates) will simply not work correctly.

The only way that I can think where this (moving the assemblies) would
(or might) work is to create a Junction Point or Mount Point to the
folder on the E: drive. I haven't tried this but using a junction point
it is plausible that this might work, that it would be possible to
reclaim disk space from an overfilled boot volume by moving the folder
to a different volume and linking it to the original location. You can
use Linkd.exe or SysInternals' Junction to query the folder on the C:
drive and find out if it is indeed a junction point.

In any case, it seems to me that this (moving SxS) is not something that
would simply have happened without your direction or approval, it would
be incredibly bad third party software design to have the software
package even try to move this folder, let alone quietly moving the
folder without user consent!

John
 
My boot volume has a 30+ GB capacity and still has about 20 GB free, so I
don't think an over-filled boot volume could have been the reason for part of
SxS to be located on E:.

I am not aware of any direction or approval by me that could have caused
part of SxS to be located on E:.

The only content of E:\Windows\winsxs\Policies is the subfolder --
\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773
which contains only two files:
8.0.50727.163.cat -- 2006-06-05 22:27, 9 KB
8.0.50727.163.policy -- 2006-06-05 24:14, 1 KB

The .cat file is digitally signed by Microsoft Developer Platform
Side-by-Side Assembly Publisher.

Over the past week, the computer has been completely re-installed on new
hard drives, so I'm not sure what the 2006 date of the above .cat and .policy
files indicates.

I have FileMon running only on a E:\Windows\winsxs filter, and will keep it
running in that configuration for a couple of weeks. If during that time
there is no activity involving E:\Windows\winsxs, I will then become more
courageous about moving it off E:.

A search of "8.0.50727.163" on the internet might indicate that
E:\Windows\winsxs is the result of install Adobe Acrobat or Adobe Reader.
However, running Adobe Acrobat and Adobe Reader does not produce any activity
that is captured by FileMon.

John, your help on this matter is greatly appreciated.

Raphael
 
Raphael said:
My boot volume has a 30+ GB capacity and still has about 20 GB free, so I
don't think an over-filled boot volume could have been the reason for part of
SxS to be located on E:.

I am not aware of any direction or approval by me that could have caused
part of SxS to be located on E:.

The only content of E:\Windows\winsxs\Policies is the subfolder --
\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773
which contains only two files:
8.0.50727.163.cat -- 2006-06-05 22:27, 9 KB
8.0.50727.163.policy -- 2006-06-05 24:14, 1 KB
Click to expand...

Those files were part of a Visual Studio C++ fix of some sort. Perhaps
the new SxS folder came about after a Windows update as one poster who
has experienced the same new folder as you have says here:
http://forums.cnet.com/5208-6142_102-0.html?forumID=5&threadID=295374&messageID=2777684


I think this may just be a temp folder that wasn't properly cleaned up
after the application of a Visual Studio hotfix, monitor or rename it
and see what happens. Let us know the outcome so that we may know what
to tell others who might post with the same question or query.

John
 
John,

FileMon disclosed no activity in E:\Windows\winsxs, so I backed-up that
folder to D:, then deleted it from E:, and then dismounted E: So far,
nothing untoward has happened, so I believe you are correct about
E:\Windows\winsxs being only a backup for a part of C:\Windows\winsxs.

Auto-updating Adobe Acrobat Pro version 7 to version 7.1 is what produced
the E:\Windows\winsxs on my computer. I discovered that when it happened on
a twin computer.

John, thanks for all your help on this matter.

Raphael
 
Back
Top