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#
Comments
Anonymous
August 07, 2008
Troubleshooting side by side problems is a not challenging task unless you break the basic checks requiredAnonymous
October 03, 2008
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.Anonymous
October 15, 2008
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.Anonymous
July 11, 2009
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 TangAnonymous
July 11, 2009
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, GauravAnonymous
July 12, 2009
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 TangAnonymous
July 12, 2009
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.Anonymous
July 12, 2009
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.Anonymous
July 12, 2009
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 TangAnonymous
July 12, 2009
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 www.DependencyWalker.com to find out what's going on.Anonymous
July 12, 2009
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 TangAnonymous
July 15, 2009
Hi Scot, Thank you very much for your kindly help. The Dependency is very useful and I now the problem is solved. Thanks, Zhanghong TangAnonymous
August 11, 2015
Where can I find (or should I #define) RT_MANIFEST and CREATEPROCESS_MANIFEST_RESOURCE_ID? What are (is?) Merge Modules?