-->

Loading a C/C++ application can fail if dependent libraries cannot be found. This article describes some common reasons why a C/C++ application fails to load, and suggests steps to resolve the problems.

If an application fails to load because it has a manifest that specifies a dependency on a side-by-side assembly, and the assembly is not installed as a private assembly in the same folder as the executable nor in the native assembly cache in the %WINDIR%WinSxS folder, one of the following error messages might be displayed, depending on the version of Windows on which you try to run the app.

• The application failed to initialize properly (0xc0000135).

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

• The system cannot execute the specified program.

Hi all, when set from Visual Studio 2005, Intel Compiler C project, it works but when trying from a command line the simplest possible command: mpiicc /Feout /Qopenmp omp-mpi.c it is not possible to run it elsewhere than on the localhost. Could you tell me what is the minimal set of compiler options necessary for the compilation of the code which uses MPI and openMP at once?

If your application has no manifest and depends on a DLL that Windows can’t find in the typical search locations, an error message that resembles this one might be displayed:

• This application has failed to start because a required DLL was not found. Re-installing the application may fix this problem.

If your application is deployed on a computer that doesn't have Visual Studio, and it crashes with error messages that resemble the previous ones, check these things:

1. Follow the steps that are described in Understanding the Dependencies of a Visual C++ Application. The dependency walker can show most dependencies for an application or DLL. If you observe that some DLLs are missing, install them on the computer on which you are trying to run your application.

2. The operating system loader uses the application manifest to load assemblies that the application depends on. The manifest can either be embedded in the binary as a resource, or installed as a separate file in the application folder. To check whether the manifest is embedded in the binary, open the binary in Visual Studio and look for RT_MANIFEST in its list of resources. If you can't find an embedded manifest, look in the application folder for a file that's named something like <binary_name>.<extension>.manifest.

3. If your application depends on side-by-side assemblies and a manifest is not present, you have to ensure that the linker generates a manifest for your project. Check the linker option Generate manifest in the Project Properties dialog box for the project.

4. If the manifest is embedded in the binary, ensure that the ID of RT_MANIFEST is correct for this type of the binary. For more information about which resource ID to use, see Using Side-by-Side Assemblies as a Resource (Windows). If the manifest is in a separate file, open it in an XML editor or text editor. For more information about manifests and rules for deployment, see Manifests.

   Note

   If both an embedded manifest and a separate manifest file are present, the operating system loader uses the embedded manifest and ignores the separate file. However, on Windows XP, the opposite is true—the separate manifest file is used and the embedded manifest is ignored.

5. We recommend that you embed a manifest in every DLL because external manifests are ignored when a DLL is loaded though a LoadLibrary call. For more information, see Assembly manifests.

6. Check that all assemblies that are enumerated in the manifest are correctly installed on the computer. Each assembly is specified in the manifest by its name, version number, and processor architecture. If your application depends on side-by-side assemblies, check that these assemblies are correctly installed on the computer so that the operating system loader can find them, as described in Assembly Searching Sequence. Remember that 64-bit assemblies cannot be loaded in 32-bit processes and cannot be executed on 32-bit operating systems.

Example

Assume we have an application, appl.exe, that's built by using Visual C++. The application manifest either is embedded in appl.exe as the binary resource RT_MANIFEST, which has an ID equal to 1, or is stored as the separate file appl.exe.manifest. The content of this manifest resembles this:

To the operating system loader, this manifest says that appl.exe depends on an assembly named Fabrikam.SxS.Library, version 2.0.20121.0, that's built for a 32-bit x86 processor architecture. The dependent side-by-side assembly can be installed either as a shared assembly or as a private assembly.

The assembly manifest for a shared assembly is installed in the %WINDIR%WinSxSManifests folder. It identifies the assembly and lists its contents—that is, the DLLs that are part of the assembly:

Side-by-side assemblies can also use publisher configuration files—also known as policy files—to globally redirect applications and assemblies to use one version of a side-by-side assembly instead of another version of the same assembly. You can check the policies for a shared assembly in the %WINDIR%WinSxSPolicies folder. Here is an example policy file:

This policy file specifies that any application or assembly that asks for version 2.0.10000.0 of this assembly should instead use version 2.0.20121.0, which is the current version that's installed on the system. If a version of the assembly that's mentioned in the application manifest is specified in the policy file, the loader looks for a version of this assembly that's specified in the manifest in the %WINDIR%WinSxS folder, and if this version is not installed, load fails. And if assembly version 2.0.20121.0 is not installed, load fails for applications that ask for assembly version 2.0.10000.0.

However, the assembly can also be installed as a private side-by-side assembly in the installed application folder. If the operating system fails to find the assembly as a shared assembly, it looks for it as a private assembly, in the following order:

1. Check the application folder for a manifest file that has the name <assemblyName>.manifest. In this example, the loader tries to find Fabrikam.SxS.Library.manifest in the folder that contains appl.exe. If it finds the manifest, the loader loads the assembly from the application folder. If the assembly is not found, load fails.

2. Try to open the <assemblyName> folder in the folder that contains appl.exe, and if <assemblyName> exists, try to load a manifest file that has the name <assemblyName>.manifest from this folder. If the manifest is found, the loader loads the assembly from the <assemblyName> folder. If the assembly is not found, load fails.

For more information about how the loader searches for dependent assemblies, see Assembly Searching Sequence. If the loader fails to find a dependent assembly as a private assembly, load fails and the message 'The system cannot execute the specified program' is displayed. To resolve this error, make sure that dependent assemblies—and DLLs that are part of them—are installed on the computer as either private or shared assemblies.

See also

Concepts of Isolated Applications and Side-by-side Assemblies
Building C/C++ Isolated Applications and Side-by-side Assemblies

-->

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> Eterra scada usa.

</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:ClientMicrosoft.VC80.MFC.MANIFEST' on line 4. Generate Activation Context failed for C:Clienttest.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#