The next level of DLL Hell – SxS.


Everybody seems to be having SxS problems. I know I have them all the time.


SxS (or side by side) was a solution Microsoft developed for people distributing the C runtime with their application.


I won't comment on whether or not this was the right solution to the problem, but I'll talk about what I do to resolve it.


Is it SxS?


Anytime an application doesn't load a dll or refuses to start for some reason, I suspect SxS. Usually you'll get something like:


The application has attempted to load the runtime library incorrectly.  Contact support for more information


This application has failed to start because the application configuration is incorrect


At this point, I do one of the following to make sure it is a side by side issue:



  • Open the event log in (XP/Vista) and look at the Application or System list. There should be a SxS error in there somewhere

  • Open the offending dll or exe using depends.exe (usually installed with Visual Studio under Common7\Tools\Bin). It will tell you if there is a SxS issue.

Do I have that CRT installed?


So one reason you might be having sxs problems is you don't even have the appropriate run time dlls installed. Usually this isn't the case, but I say it here first just to make sure you check.


To check if you do:



  • Open the event from the event viewer that identifies what dll it is trying to load. Vista shows something like so:


Component identity found in manifest does not match the identity of the component requested. Reference is Microsoft.VC80.ATL blah blah blah



  • Go to your Windows\WinSxS directory and see if you have a directory with a name containing the reference. Vista could have multiple.

If you find a directory containing the name of the runtime, then some version of that runtime is installed. You probably need to redirect.


Redirecting - Fixing the problem


Obligatory warning: Mucking with system files can screw stuff up later on. Not that I've had problems after doing any of these fixes, but people say it's unsupported. I wouldn't recommend this as a "fix" but rather a workaround on your development machine.


Anyway, here's what I do depending upon the platform:



XP/2003 Server



  • Go to the event log. Find the error that names the dll you are having trouble with (there might be 3 or more errors for your one side by side load)

  • Go to the Windows\WinSxS\Policies\<goofy directory containing your CRT dll name>

  • Edit the .policy file with the largest number.

  • Change the binding redirect to be like so:


<bindingRedirect oldVersion="9.0.0.0-9.0.65535.65535" newVersion="9.0.xxxxxx.xxxxx"/> 



  • The critical part here is that the the newVersion value matches the policy file's main number. Here's one on my machine:


  •  


    name="policy.9.0.Microsoft.VC90.DebugCRT" version="9.0.20223.44800"



Make sure the number at the top of the file matches the newVersion you type in.


Vista



  • Go to the event log. Find the error that names the dll you are having trouble with (there might be 3 or more errors for your one side by side load)

  • Go to the Windows\WinSxS\Manifests

  • Find the newest manifest file with the name like so


x86_policy.8.0.microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.762_none_8e053e8c6967ba9d.manifest




The important parts being x86_policy and microsoft.vc80.atl - this name matches the runtime you are trying to redirect. The rest of the name doesn't really matter, although it should be the newest file and probably the highest version x86_policy file in that directory for your runtime.


My friend John discusses another alternative (at least on Vista) to find the appropriate file: sxstrace



  • Edit this file and change the binding redirect to be like so:


<bindingRedirect oldVersion="8.0.0.0-8.0.65535.65535" newVersion="8.0.xxxxxx.xxxxx"/> 



  • The critical part here is that the the newVersion value matches the policy file's main number. Here's one on my machine:


  •  


    name="policy.8.0.Microsoft.VC80.ATL" version="8.0.50727.44800"



Make sure the number at the top of the file matches the newVersion you type in.



  • Here's another caveat for vista = saving the file. You probably aren't the owner of this file. You need to remove whoever is the owner, and make yourself owner of this file before you can save it. I'll leave that step up to the user for brevity's sake.

After changing the appropriate policy file, your app should start to work. If it doesn't, hey you might have a dependency on another part of the CRT. Check the event log again 🙂


Update: How to tell when this isn't going to work


So I finally ran into a case when this workaround failed. When the CRT is actually different and your application is using the wrong CRT! Duh.


You'll get something like:



---------------------------
devenv.exe - Entry Point Not Found
---------------------------
The procedure entry point
?replace@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@V?$_String_const_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@2@0ABV12@@Z could not be located in the dynamic link library MSVCP80.dll.
---------------------------
OK  
---------------------------


In this case you actually need to go through the correct channels - like trying to find this version of the CRT and installing it. Should be installed under:



Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86


You might also try a manifest for the appropriate dlls. Here's a blog entry about it.


Skip to main content