Part 1: Troubleshooting VC++ Side by Side Problems

Let’s go back to the older days, when code sharing was an integral decision taken by application developers. Code sharing allowed developers to write efficient and light-weight applications with less memory utilization. Creating a shared component in the form of Dynamic Link Library (DLL) soon became an obvious choice to achieve code sharing. However, there were costs to sharing. Sharing means that applications become interdependent upon one other. But, changes to one DLL may produce unintended effects in other DLLs. Typically; an application may become dependent on a particular version of a DLL. Another application may be installed with an upgraded (or downgraded) version of that DLL, and the first application may suffer from that change. In the extreme, applications that once worked well mysteriously start to function oddly, or even fail. This condition was often referred to as "DLL Hell."

To minimize the DLL Hell, Side-by-Side (SxS) execution was introduced in Windows XP. SxS execution allows multiple versions of the same component to run at the same time in different processes. Applications can then use the specific version of a component for which they were designed and tested, even if another application requires a different version of the same component. This arrangement allows developers to build and deploy more reliable applications because developers are able to specify the version of the component they will use for their application, independent of the other applications on the system.

Windows maintains all VC++ libraries into a central native folder, “%windir%\winsxs”. This is the central shared cache for all the VC++ SxS assemblies. “Native Fusion Loader”, one of the Operating System’s components, picks up multiple versions of these DLLs as required. Fusion takes care of loading all the correct dependencies of the application, thus avoiding the pitfalls of the DLL Hell. Fusion loader is part of the Operating System, but is different from the traditional NT Loader. Note that Fusion is also the internal name of the .NET CLR assembly loader and should not be confused with Native Fusion Loader.

Visual Studio® 2005 first shipped VC++ libraries as SxS assemblies including ATL, CRT, MFC, MFCLOC, and OpenMP. These libraries are used to build your application. In order to ensure that your Visual C++ application will run on a computer without Visual C++ installed, you may have to redistribute Visual C++ assemblies with your application and ensure they are installed on the target computer. After successfully deploying your application, you might see that the application fails to start with SxS errors. This blog attempts to help you understand and troubleshoot some of the common SxS problems. For simplicity purposes, I have mentioned the problems as scenarios.

Following are basic checks that you should always track even before troubleshooting any SxS issue:

1. Your application should have a valid manifest file either embedded as a resource with ID RT_MANIFEST or in the form of external <Application>.exe.manifest. Note that Windows XP honours an external manifest over an embedded one, whereas Windows Server 2003, Vista and Windows Server 2008 prefer embedded over external. The same applies to a DLL as well; however you should not have external manifest file for your DLL. The easiest way to check the contents of an application/DLL manifest file is by opening it in notepad and searching for “manifest”.

2. Make sure the resource ID for executable is CREATEPROCESS_MANIFEST_RESOURCE_ID and for a DLL it should be ISOLATIONAWARE_MANIFEST_RESOURCE_ID

Since Windows XP, Windows reserves a new type of resource RT_MANIFEST for SxS manifest

#define RT_MANIFEST MAKEINTRESOURCE (24)

#define CREATEPROCESS_MANIFEST_RESOURCE_ID MAKEINTRESOURCE (1)

#define ISOLATIONAWARE_MANIFEST_RESOURCE_ID MAKEINTRESOURCE (2)

CREATEPROCESS_MANIFEST_RESOURCE_ID (1) : If an executable has a resource of type RT_MANIFEST, ID 1, Windows will create a process default activation context** for the process. The process default activation context will be used by all components running in the process.

ISOLATIONAWARE_MANIFEST_RESOURCE_ID (2): This is used primarily for DLLs. It should be used if the DLL wants private dependencies other than the process default.

**Activation contexts are data structures in memory that contain information that the system can use to redirect an application to load a particular DLL version. Windows reads the application manifest file to constructs the activation contexts. For more information, see Activation Context.

3. Make sure you have all the required VC++ SxS libraries correctly installed. The following table will help you understand which redistributable is required to install depending upon your application usage.

Note: Using the VC++ Redistributable package is one of the easiest ways to install VC++ SxS assemblies, but I would recommend you to deploy your application with Merge Modules instead. These are more powerful than the vcredist package, and have a built-in reference counting mechanism to avoid uninstalling drawbacks which you might face with redistributables. For more information, see

Redistributing Using Merge Modules.

4. Looking at Event Viewer Logs is the best way to get started troubleshooting. On Vista you can use sxstrace.exe. Unfortunately this tool is not available on Windows XP or 2003.

If you are still face challenges in running your application, get ready to enter the world of Troubleshooting VC++ SxS problems. In, Part 2: Troubleshooting VC++ Side by Side Problems I have explained some of the common scenarios that will help you fix SxS problems.

- Gaurav Patole.

Developer Support VC++ and C#