Troubleshooting side by side problems is not a challenging task unless you break the basic checks which are required to successfully run your application. These rules help you track the problem area in your application at the first stage. For more information, see Part 1: Troubleshooting VC++ Side by Side Problems. This blog attempts to help you troubleshoot some of the common SxS problems. For simplicity purposes, I have mentioned the problems as scenarios.
Following are some of the scenarios that will help you to troubleshoot SxS issues:
Scenario 1: Application fails to run with one of below error message:
The application failed to initialize properly (0xc0000135).
This application has failed to start because the application configuration is incorrect. Reinstalling application may fix this problem.
The system cannot execute the specified program.
Possible Cause: Missing Visual C++ SxS assemblies.
Resolution: Install the correct version of Visual C++ SxS assemblies.
More Information: If a manifest is present in your application but a required Visual C++ library is not installed in the WinSxS folder, you may get one of the above error messages depending on the version of Windows on which you try to run your application.
Scenario 2: When I run my application, I get a Runtime Error R6034.
”An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information.”
Cause: C runtime library is loaded without using a manifest. This generally happens when application does not have a valid manifest.
Resolution: You should provide a valid manifest file for your application. Rebuilding your application with Visual Studio automatically puts the manifest into the resulting EXE or DLL file.
This can be done programmatically using the bellow code:
#pragma comment(linker, "\"/manifestdependency:type='Win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='X86' publicKeyToken='1fc8b3b9a1e18e3b' \"")
You can also embed the manifest using mt.exe. For more information, see How to: Embed a Manifest Inside a C/C++ Application
More Information: The error message can come from different sources. This might even happen if you are mixing the Debug and Retail build of CRT. So if you try to run Debug build of your application and you use a DLL which was built with Release build, you might get this error. Another source of this problem could be incorrect inclusion of CRT header files. Also, there is a known bug that if you use Visual Studio 2005 SP1 to build your application using vcbuild, the manifest information fails to embed and thus results in R6034. This bug was fixed in VS 2008.
Scenario 3: When I run my application, I get a side-by-side error.
“The application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.”
Event viewer shows error details similar to “Activation context generation failed for "…\TestSxS.exe". Error in manifest or policy file. A component version required by the application conflicts with another component version already active.”
Cause: Not all parts of application’s source code are built with the same version of VC++ libraries.
Below is the application manifest file that has two references for the same assembly. This causes the application to fail.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
Resolution: Rebuild all parts of your code with the same VC++ libraries. Remember to check that old versions of headers and import libraries for VC++ libraries are not on INCLUDE and LIB path and they are not used during the build.
More Information: If you cannot rebuild all your code and use one version of VC libraries, there are two ways to work around this problem:
Workaround#1: Install the newer version (8.0.50727.762 in this case) of VC++ MSMs or VCRedist.EXE on a machine where your application is going to run. Once policy for VC++ assemblies is installed on that machine they are going to redirect all loads of older versions (8.0.50608.0) to the newest version available on the machine.
Workaround#2: If you are redistributing VC++ libraries in application’s local folder, you need to add an application configuration file that redirects an attempt to load 8.0.50608.0 version to 8.0.50727.762 version.
For more information, see http://blogs.msdn.com/nikolad/archive/2007/03/29/a-solution-to-two-references-to-different-versions-of-crt-mfc-atl-in-one-application-manifest-file.aspx
Scenario 4: My application fails to start with below error message.
“This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem.”
Cause: Mixing of retail and debug components.
Resolution: Add the retail CRT library reference in the application manifest file.
More Information: Typically this error occurs because you are mixing retail and debug components or maybe you don’t even have the VC++ libraries. Make sure you have the correct version of VC++ libraries installed on your machine. Also, a very common scenario is a debug build of an application which is pulling in a retail version of a static library. The scenario could be the exact reverse and the error message in this case would reference msvcr80d.dll.
This can be worked around by adding a reference to retail CRT in the application manifest manually or by adding the following to a header.
#pragma comment(linker, "\"/manifestdependency:type='Win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='X86' publicKeyToken='1fc8b3b9a1e18e3b' \"")
If you are not mixing the retail and debug libraries, probably you need to investigate further to find the cause of MSVCR80.dll not getting loaded. There might be some piece of code that intercepts the DLL. If this is true, it will cause the application to show this error message. Remember when you intercept the call by LoadLibrary you are actually asking the NT Loader to load this DLL and not Fusion Loader. Intercepting and hooking of these DLLs is not a supported.
Scenario 5: I am having Application local deployment for my MFC application. The application works fine but the event log shows below SxS errors:
Component identity found in manifest does not match the identity of the component requested Syntax error in manifest or policy file "C:\Client\Microsoft.VC80.MFC.MANIFEST" on line 4. Generate Activation Context failed for C:\Client\test.dll. Reference error message: The operation completed successfully.
Cause: The assembly manifest of Microsoft.VC80.MFCLOC is incorrect.
Resolution: The assembly manifest of Microsoft.VC80.MFCLOC has version 8.0.50727.42 instead of 8.0.50608.0. You need to change this manually in the manifest. Actually Microsoft.VC80.MFCLOC may not be referenced by the application but is referenced by MFC80[ud].dll. So you also need to copy the Microsoft.VC80.MFCLOC directory under Microsoft.VC80.MFC directory.
More Information: These errors are benign in nature and won’t cause the application to stop functioning. Also remember to correctly copy the MFCLOC under the correct application directory. Application directory is the directory a binary with manifest is located.
Scenario 6: I am having Application local deployment. My application is built on a machine having VS2005 SP1. It links to a DLL which was built with VS2005 RTM version. I get below error:
“The application failed to initialize properly (0xc0150002). Click on OK to
terminate the application.”
Cause: Not all parts of application’s source code are built with the same version of VC++ libraries.
Resolution: Rebuild all parts of your code with the same VC++ libraries.
More Information: Remember this is not recommended way of deploying the application. Every binary which is part of the application should be built using the same VC++ libraries.
If you cannot rebuild all your code and use one version of VC++ libraries, there are two ways to work around this problem:
Workaround#1: Install the RTM version (8.0.50727.42) of VC++ MSMs or VCRedist. Once policy for VC++ assemblies is installed on that machine they are going to redirect all loads of older versions (8.0.50608.0) to the newest version available on the machine.
Workaround#2: Manually update the DLL manifest file to refer to the SP1 version. This can be done by changing the embedded manifest file inside your DLL, or you can provide an external <MyDLL>.dll.2.config with the binding redirection tag.
<configuration>
<windows>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
<bindingRedirect oldVersion="8.0.41204.256-8.0.50727.762" newVersion="8.0.50727.762"/>
</dependentAssembly>
</assemblyBinding>
</windows>
</configuration>
Scenario 7: My application works on Windows XP but fails on Windows Server 2003 with SxS errors.
Possible Cause: Multiple manifest files might exist.
Resolution: Remove one of the manifest files.
More Information: On Windows XP, the stand-alone manifest overrides the embedded manifest whereas in Windows Server 2003/Vista and onwards, the embedded manifest always overrides the stand-alone manifest.
- Gaurav Patole.
Developer Support VC++ and C#
