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.

















































Usage


Redistributable


Description


Application built with Visual Studio 2005 RTM version (8.0.50727.42)


vcredist_x86.exe


Runtime components for x86 platform


vcredist_IA64.exe


Runtime components for IA64 platform


vcredist_x64.exe


Runtime components for x64 platform


Application built with Visual Studio 2005 SP1 version (8.0.50727.762)


vcredist_x86.exe


Runtime components for x86 platform


vcredist_IA64.exe


Runtime components for IA64 platform


vcredist_x64.exe


Runtime components for x64 platform


Application built with Visual Studio 2008  version (9.0.21022.8)


vcredist_x86.exe


Runtime components for x86 platform


vcredist_IA64.exe


Runtime components for IA64 platform


vcredist_x64.exe


Runtime components for x64 platform


Application built with Visual Studio 2008  SP1 version (9.0.30729.1)


vcredist_x86.exe


Runtime components for x86 platform


vcredist_IA64.exe


Runtime components for IA64 platform


vcredist_x64.exe


Runtime components for x64 platform


 


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#

Comments (13)

  1. Troubleshooting side by side problems is a not challenging task unless you break the basic checks required

  2. SMSI says:

    We have a weird issue on Vista 64 regarding side-by-side issue on on an upgrade where we are using the redistributable as merge modules. The upgrade happens but the service reports error 14001.. Both the earlier and the later version of hte product include the same redist merge modules (both x86 and x86_X64). The service is running as a 32-bit process on 64 bit systems (Wow64). both the earleir (1.0) and the later (1.1) version install and run fine if installed from a fresh ghost on the system. however, if the 1.0 is already installed and the 1.1 version is used to upgrade then the service startup reports the side-by-side error.

    Running a repair on the MSI fixes things (without anything perceptively changing in the winsxs folder or manifests)

    Another way to solve this situation is to run the VC redist (x86) EXE redistribution package. That fixes this situation as well..

    But not sure what is the problem that happens using the merge module only on an upgrade and only in Vista 64 for a 32 bit process that dynamically links CRT/MFC libs.

  3. asmartpointer says:

    Error 14001 i.e. ERROR_SXS_CANT_GEN_ACTCTX is "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."

    If you are dynamically linking to CRT library make sure the module being loaded has a valid manifest and correct installation of the CRT in the WinSXS folder. Since the process is running as 32-bit you need to install 32-bit Merge Modules/VCRedist.

  4. tang says:

    Dear all,

    I have a similar problem. I built a ‘x64’ version of program (console exe file) by VS.2008 (SP1) in Vista x64 system. The program works normally in this computer, however, when I copied it to another machine with Windows xp x64 system, the same error displayed:

    This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

    Could anyone help me to solve this problem?

    Thanks,

    Zhanghong Tang

  5. asmartpointer says:

    Hi Tang,

    You need to make sure you install all the required x64 libraries on your XP x64 system. Did you tried step 3 mentioned above?

    Thanks,

    Gaurav

  6. tang says:

    Hi Gaurav,

    Thank you very much for your kindly reply.

    I tried step 3 mentioned above (installed in the computer of Vista system but not the Window Xp x64 system, since we suppose the machine with Windows XP x64 system is from customer and he doesn’t installed anything except the OS system).

    In addition, for the same project, I can build the x64 version with VS2005 and VS2008 on Windows XP 32 bit machine and it works on the Windows XP x64 system. Do you know what could lead to such problem?

    Thanks,

    Zhanghong Tang

  7. Scot says:

    You must install all DLLs on which your program is dependent.  This is just the rule.  Never assume that your dependencies will have been installed by someone else.  If you depend on the x64 CRT for VS 2008 SP1, then install it.  Your error implies that you did not install it.

  8. Scot says:

    You must install all DLLs on which your program is dependent.  This is just the rule.  Never assume that your dependencies will have been installed by someone else.  If you depend on the x64 CRT for VS 2008 SP1, then install it.  Your error implies that you did not install it.

  9. tang says:

    Hi Scot,

    Thank you very much for your kindly reply.

    But why the program works when it is built on the machine with Windows XP 32 system? On the other hand, I remembered that if some dependent DLLs lost, some other error information related to the DLLs will pupped up. Thirdly, I built the program by "static link" (/MT) and it should not rely on other DLLs.

    Any other possibility could lead to this problem?

    Thanks,

    Zhanghong Tang

  10. Scot says:

    The 32-bit CRT is a different set of DLLs than the 64-bit ones.  Maybe the 32-bit DLLs were installed by someone else already, but not the x64 ones.  If you muilt with /MT, you should not have a direct dependency.  Maybe something else to which you linked has the dependency.

    Use the Dependency Walker tool from http://www.DependencyWalker.com to find out what’s going on.

  11. tang says:

    Hi Scot,

    Thanks again for your kindly reply.

    I built the x64 programs by VS2005 and VS2008 on a machine with Windows XP 32 OS installed and both programs work on the target machine. But when the same project is built on the machine with Vista x64 OS installed, the program can’t work on that target machine.

    I will try to download the Dependency to check the problem.

    Thanks,

    Zhanghong Tang

  12. tang says:

    Hi Scot,

    Thank you very much for your kindly help.

    The Dependency is very useful and I now the problem is solved.

    Thanks,

    Zhanghong Tang

  13. OffByOne says:

    Where can I find (or should I #define) RT_MANIFEST and CREATEPROCESS_MANIFEST_RESOURCE_ID?

    What are (is?) Merge Modules?