Part 2: Troubleshooting VC++ Side by Side Problems

Artikel
08/07/2008

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.”

Scenario 1

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.”

Scenario 2

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"?>

</dependentAssembly>

</dependency>

</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 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.”

Scenario 3

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.

<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#

Comments

Anonymous
August 07, 2008
PingBack from http://blogs.msdn.com/dsvc/archive/2008/08/07/part-1-troubleshooting-vc-side-by-side-problems.aspx
Anonymous
August 22, 2008
The comment has been removed
Anonymous
August 25, 2008
@Jeff: <publisherPolicy> is an CLR environment variable and is ignored by Win32 Fusion Loader. Since your application is unmanaged, this will not affect the application policy behaviour. Looks like your Vista system already has the latest policy (SP1) which application requires. Thus it works. Not sure if the XP machine has the same SxS assemblies installed? Also a crude way to make your application work is to entirely remove the redundant older references from application manifest file. This can be done manually using Visual Studio or using mt.exe.
Anonymous
September 02, 2008
Gaurav, Given that <publisherPolicy> is a CLR environment variable, I understand why my XP system is behaving as it is with my unmanaged application. But it is still not clear why my Vista system is behaving as it is. If my application configuration file for the offending DLL has <publisherPolicy apply="yes"/>, then the offending DLL finds the newer version of the CRT and the application succeeds. But if my application configuration file for the offending DLL has <publisherPolicy apply="no"/>, then the offending DLL does not find the newer version of the CRT and the application fails (due to conflicts with other DLLs loading the newer CRT). So under Vista, it appears that the Win32 Fusion Loader is processing the <publisherPolicy> statement. I'm happy with this behavior, but it's not clear why it is occurring. What am I missing? Also, the offending DLL that I'm using the application configuration file for is a third-party DLL that our licensing prevents us from modifying. So unfortunately I can't modify the application manifest file. Any other suggestions on how we can "trick" XP into effectively recognizing the <publisherPolicy> statement? -Jeff
Anonymous
September 09, 2008
To be more clear, configurationruntimepublisherPolicy controls the CLR and configurationwindowspublisherPolicy controls the Win32 Fusion loader. Remember, <publisherPolicy apply="yes"/>, is the default. I suspect it is not the source of the problem where the policy is not getting applied. If the manifest cannot be modified you need to ask the DLL vendor to do it for you. The only know solution to this problem is to rebuild all the dependencies of the application with the latest version.
Anonymous
September 17, 2008
Are there any other files or registry settings that I can check that would override the <publisherPolicy apply="yes"/> statement in my application configuration file and force the policy to not be applied?
Anonymous
October 05, 2008
Hello DSVC team, I am trying a simple MFC dialog app in VS2005 on Vista, but getting the SxS errors. The event log points that, my app is built with .50608 versions of CRT/MFC , but Vista has .5727...And when i try to copy the required DLL/Manisfest in to Winsxs, i get permission denied error, tho i am admin. Question :

How and which vcredist can i use , if at all to resolve this error ?
Some links point to use MSM, but i really still dont want to deploy, i just want to run and debug for now.. any answers most appreciated.. kirann

Anonymous
October 10, 2008
Hi Kiran, Manually modifying the "WinSxS" folder is never recommended and it should be only done by an authored installer. From the details you mentioned it is difficult to understand the error you receive. Could you please provider event log entries and sxstrace logs? I would recommend you to read the "Part 1: Troubleshooting VC++ Side by Side Problems" of this blog. It should answer your questions about which vcredist to install. Thanks, Gaurav
Anonymous
October 12, 2008
Thanks Gaurav, i read part 1 , and wud give it a try to install correct redist and will update in case it still crashes. cheers kirann
Anonymous
October 16, 2008
This is probebly trivial to you chaps, but grateful for any help: I have been using mageui to build manifests to deploy a program. The program's manifest (generated using cl/clr) refers to dependent assemblies microsoft.vc90.mfc and microsoft.vc90.crt. If I don't put msvcp90.dll, msvcr90.dll ... mfcm90u.dll etc in the distribution folder, the install fails because it can't find them. If I add them to the distribution directory but don't re-run mage to add them to the application manifest, the install finds them but then objects that "The + Manifest XML signature is not valid. + No signature was present in the subject." If I add them to the distribution directory and re-run mage, including them in the distribution, the install fails because it says "The file ......msvcr90.dll (etc) already exists". This presumably is because it's trying to install the dll's once because it knows they are part of the microsoft.vc90.mfc assembly, and once again because they're in the list for deployment. So far this has only consumed about a week of fruitless time...
Anonymous
October 21, 2008
Hello, I have a Visual Studio 2008 solution with several C# and C++ projects. Both type of projects create managed dlls and use native assemblies that are installed into the WinSxS folder. Creating and installing the native assemblies so far worked just fine. I then added their signature to the already existing manifest (the ones that reference the C/C++ runtime) files of the managed C++ projects. When I use these managed C++ assemblies everything works just fine, i.e. the native assemblies are loaded from the WinSxS folder as expected. But it does not work with the C# assemblies. By default VS2008 does not (to my knowledge) create a manifest for them so I manually created the manifests. Basically the manifests are the same as the ones for the managed C++ assemblies except that they do not reference the C++ runtime. However, when I start the test application it fails. Reason is that the native assemblies are not loaded from the WinSxS folder. It seems to me that the manifests for the C# assemblies are simply ignored. First I tried to simply put them into the same folder as the assembly, then I embedded them into the C# assemblies using the mt.exe. But nothing worked. I validated the manifests using mt.exe and it states that they are ok. It is not clear to me why they are ignored. Actually I do not understand why it should make a difference, managed C++ and C# create the same output at the end... However, I can reproduce that behaviour and it simply does not work. The native assemblies referenced in a manifest attached to a managed assembly created by a Visual Studio 2008 C# project are never loaded. Can you explain that?
Anonymous
November 14, 2008
The comment has been removed
Anonymous
May 12, 2009
from DD: Need help, please!!!!!!!! I upgraded my application to VS2008 and having problem registering my dlls. This is the error I received after the VS2008 upgrade: Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis. After I have read "Troubleshooting Manifest-Related Issues" and follwed the suggestion I added the followings: #define _BIND_TO_CURRENT_MFC_VERSION=1, #define _BIND_TO_CURRENT_CRT_VERSION=1, #define _BIND_TO_CURRENT_ATL_VERSION=1 to the top of my stdafx.h and rebuilt the application. I then looked at the manifest and now I see it points to version '9.0.30729.1' as shown below: <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.30729.1' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC90.MFC' version='9.0.30729.1' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC90.ATL' version='9.0.30729.1' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> However, when I tried to register my new dll again I received the same error for version 9.0.21022.8 as shown below: Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.1" could not be found COULD SOMEONE PLEASE HELP ME TO RESOLVE THIS SIDE-BY-SIDE PROBLEM, PLEASE.......I have a deadline on my project and I need to get this fix asap. I appreciate very very much for your helps
Anonymous
May 12, 2009
The comment has been removed
Anonymous
August 07, 2009
Hello, i'm building some customs dlls like gdi32.dll to be notified when the user do some tasks. I want Word and some other text editors to use my gdi32.dll. So I added "<file name="gdi32.dll" /> in the application manifest file, and copied my dll to the application folder and it's working fine. But I have to sopy my dll in each folder, so i ve made some researshes and found that i can add "loadFrom" to indicate where to use my dll. But in the case of Word it isn t working, in fact with Office applications. word have no manifest file basicly, so i created one using the Excel's one. When I have my dll in the folder without the loadFrom its ok, otherwise it tells me at start that : "_crt_debugger_hook cannot be found in MSVCRT80.DLL" ... Why when i tell where to get my dll this error occurs ? It makes no sense to me ... . I found that function in one the msvcr dlls located in SxS folder. I copied it to Office12 folder and i still got the same error. I don't get where i m making a mistake. If you could help me on this point it would be great. Best regards Jean-Paul
Anonymous
August 12, 2009
Hi Guyz, we are porting activex plugin from 32bit to 64bit with VS2005. My output .ocx files shows that it depends on mfc80.dll and msvcr80.dll from dependency walker. in dependency walker it shows that mfc80.dll it picked from amd64_microsoft.vc80.mfc_8.0.50727.42 folder and msvcr80.dll from amd64_microsoft.vc80.crt_8.0.50727.1433 folder. when dependency walker tries to find the dependency of mfc80.dll it shows that msvcr80.dll not found but it is there in another folder as mentioned above. so, As first step i tried to register my .ocx file using regsvr32. it register successfully. But when i tried to download the .ocx file it crashes. Means generated cab file and using html object tried to download.... when i look at the manifest file it generates automatically as a build process it shows mfc and msvcrdll version as 5.0.50608.0..... how should i resolve this?
Anonymous
August 12, 2009
Hi Haresh, Dependency walker is a good tool for checking the dependencies of the module. However, for SxS modules it does not work that great. I would see if Windows Event Log gives me any hint if its SxS issue. Also, did you visit http://blogs.msdn.com/dsvc/archive/2008/08/07/part-1-troubleshooting-vc-side-by-side-problems.aspx to see if your control passes the basic checks? Thanks, Gaurav
Anonymous
September 02, 2009
The comment has been removed
Anonymous
June 29, 2010
Hi, I know this problem is getting a bit old in the tooth, but I am suffering from scenario #6. In workaround #1, I do not understand why you say "Install the RTM version..." . Did you not mean "Install the SP1...." version? Andrew
Anonymous
July 05, 2012
Hello,I have the same situation as Scenario 3. I have to plug the third part DLL(Test.dll),and i also have the Test.dll.menifest. But it still show the R6034 Error, do you have any other suggestions? Thank you. <?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' /> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC80.MFC' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> </assembly>
Anonymous
January 21, 2013
The comment has been removed
Anonymous
January 22, 2013
It seems the application is built on a machine with a higer version of CRT v9.0.30729.6161. So the application is adding the manifest with the version latest on the build machine. However, on the machine where this applicaiton is executed, does not seem to have the same version but rather 9.0.30729.4148. Please make sure you have the same version of CRT assemblies deployed which the applicaiton manifest demands.
Anonymous
August 11, 2015
I have a small dialog-based solution with a single project that uses MFC and CRT. It has been built and deployed on a machine other than the workstation that was used to build it. The manifest created by VC++ 2005 specified 8.0.50608.0 for CRT, MFC, DebugCRT and DebugMFC. On the target machine, the WinSxs folder contains versions 8.0.50727.4053 and 4940 for the CRT, and the MFC only has the 4053 version. No versions of the Debug versions are installed. Even though you supplied 7 scenarios, you managed to miss my specific issue. Nevertheless, it seems clear to me that the solution is to install the 50608 version of the required libraries. That raises two questions:

Where can I find specific versions of these libraries?
How do I go about installing them? Thank you

Freigeben über

Part 2: Troubleshooting VC++ Side by Side Problems

Comments

Zusätzliche Ressourcen