How to Debug 'The System cannot Execute the specified program' message.

[アーティクル]
06/09/2005

Here is another unofficial preview of a topic that I am going to send out to our UE team later today for publishing on MSDN. As always, standard disclosure that this post is provided "AS IS" with no warranties, and confer no rights and use of this sample is subject to the terms specified at https://www.microsoft.com/info/cpyright.htm Please feel free to send me any feedback (other the grammar and spelling errors :-)).

Loading C/C++ application may fail if dependent Visual C++ libraries can not be found. In this section the most common reasons for a C/C++ application failing to load are described with proposed steps to resolve the problems.

One of the most common errors messages one may see when dependent Visual C++ DLLs cannot be found is a message box with a text saying “ The system cannot executed the specified program”. Below several things are listed that may help to understand a reason for this error.

Dependency walker can show most of dependencies for any particular application or Dll. If you see some of DLLs are missing, please insure that these DLLs are correctly installed on the computer on which you are trying to run your application.
Manifest is used by the operating system loader to load assemblies that your applications depend on. It can be either embedded inside the binary as a resource or saved as an external file in the application's local folder. To check whether manifest is embedded inside the binary, open your binary in Visual Studio and browse through resources of this binary. You should be able to find a resource with name RT_MANIFEST. If you cannot find manifest embedded inside the binary, check for external file named something like <binary_name>.<extension>.manifest.
1. If manifest is not present, you need to ensure that the linker generates manifest for your project. You need to check linker's option "Generate manifest" in Project Properties dialog for this project.

Note: It is not supported to build VC++ projects without manifest generation. All C/C++ program built in Visual C++ 2005 have to include a manifest describing its dependencies on Visual C++ libraries.

If manifest is embedded inside the binary, ensure that ID of RT_MANIFEST is correct for this type of the binary. Such for applications ID should be equal to 1, for most DLLs ID should be equal to 2. If you found this file export it as a file and open in a XML or just a text editor. For more information on manifest and rules for its deployment, see Manifest.
Please be aware that on Windows XP, if an external manifest is present in the application's local folder, the operating system loader uses this manifest over a manifest embedded inside the binary. On Windows Server 2003, this works vice versa – external manifest is ignored and embedded manifest is used when present.
It is recommended for all DLLs to have a manifest embedded inside the binary. External manifest are ignore when DLL is loaded thought LoadLibrary() call. For information see, Assemblies manifest.
Check all assemblies enumerated in the manifest for their correct installation of the computer. Each assembly 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 installed on this computer properly, so they can be found by the operating system loader that uses steps specified in Searching sequence while searching for dependent assemblies. Remember that 64bit assemblies cannot be loaded in 32bit process and cannot be executed on 32bit operating system.

Example:

Let's assume we have an application appl.exe built with Visual C++ 2005. This application may have its manifest either embedded inside appl.exe as a binary resource RT_MANIFEST with ID equal to 1, or store as an external file appl.exe.manifest. The content of a manifest may be something like below:

</dependentAssembly>

</dependency>

</assembly>

To the operating system loader this manifest says that appl.exe depends on an assembly named Microsoft.VC80.CRT, version 8.0.50215.4631 and built for 32bit x86 processor architecture.

The dependent side-by-side assembly can be installed as either shared assembly or as private assembly. For example, Visual Studio 2005 installs CRT assembly as a shared side-by-side assembly and it can be found in the directory

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50215.4631_x-ww_b7acac55 (assuming C:\Windows is the operating system's root directory).

The assembly manifest for a shared Visual C++ CRT assembly is also installed in

C:\WINDOWS\WinSxS\Manifests\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50215.4631_x-ww_b7acac55.manifest

And it identifies this assembly and lists its content (DLLs that are part of this assembly):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

</assembly>

Side-by-side assemblies can also use publisher configuration files, also called policy files, to globally redirect applications and assemblies from using one version of a side-by-side assembly to another version of the same assembly. You can check policies for shared Visual C++ CRT assembly in

C:\WINDOWS\WinSxS\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773\8.0.50215.4631.policy

which content is something like

</assembly>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

</dependentAssembly>

</dependency>

</assembly>

The policy above basically specifies that any application or assembly that asks for version 8.0.41204.256 of this assembly should use version 8.0.50215.4631 of this assembly, which is the current version installed on the system. If a version of the assembly mentioned in the applications manifest is specified in the policy file, the loader looks for a version of this assembly specified in the manifest in the WinSxS folder, and if this version is not installed load fails. And if assembly of version 8.0.50215.4631 is not installed also, load fails for applications that ask for assembly of version 8.0.41204.256.

However CRT assembly can also be installed as a private side-by-side assembly in the applications local folder. If the operating system fails to find CRT or any other assembly as a shared assembly, it starts looking for this assembly as a private assembly. It searches for private assemblies in the following order:

1. Check the application local folder for a manifest file with name <assemblyName>.manifest. In this example, the loader tries to find Microsoft.VC80.CRT.manifest file in the same folder as appl.exe.

a. If the manifest has been found, the loader loads CRT Dll from the application folder.

b. If CRT DLL is not found, load fails.

2. Try to open folder <assemblyName> in appl.exe local folder and if it exists, load manifest file <assemblyName>.manifest from this folder.

a. If the manifest has been found, the loader loads CRT DLL from <assemblyName> folder.

b. If CRT DLL is not found, load fails.

See Assembly Searching Sequence for more detailed description on how loader searches for dependent assemblies. If the loader fails to find dependent assembly as a private assembly, load fails and "The system cannot executed the specified program” is display. To resolve this message dependent assemblies and DLLs that are part of them has to be installed on this computer as either private or shared assemblies.

Related Sections

About Isolated Applications and Side-by-side Assemblies

Assembly Searching Sequence

Manifest

Publisher configuration files

Comments

Anonymous
November 02, 2006
The comment has been removed
Anonymous
November 21, 2006
I see a wierd situation, for some reason The manifest file is looking for 2 sets of DLL's as dependencies when I port it to my friends machine, whereas indicates only 1 dependency in mine. How is this supposed to work, is this an OS related issue, or an aplplication related issue. Any Suggestions ?
Anonymous
November 21, 2006
THe manifest is built together with the final binary. Check build.log and you may find why application builds differently on your friends machine. You may also get help on resolving this issue from the community on forums when you have more details, http://forums.microsoft.com/msdn/showforum.aspx?forumid=29&siteid=1. Thanks, Nikola
Anonymous
April 17, 2007
In my case (with problem occuring only on other machine) manifest, paths and everything was alright, but because the app was compiled in debug mode, I had to create setup to allow DLLs to be placed on target machine. . http://msdn2.microsoft.com/en-us/library/aa985618(VS.80).aspx
Anonymous
April 17, 2007
Magh, I have to bring to your attention that debug version of an code is not redistributable and none of the debug versions of the various Visual C++ dynamic-link libraries (DLLs) are redistributable. Debug versions of an application and Visual C++ libraries can only be deployed to another computer internal to your development site for the sole purpose of debugging and testing your application on a computer that does not have Visual C++ 2005 installed. Please make sure your setup is not redistributing debug versions of VC++ DLLs on release of your product. More information is here, http://msdn2.microsoft.com/en-us/library/ms235299(VS.80).aspx Nikola
Anonymous
April 19, 2007
Dear Nikola, I thank you first of all for your valueable post. This post is very much help to solve my VC++ Problem. I need one clarification regarding to install Manifest file. I am developing VC++ based application(Wrapper). My project generates a manifest file. how do i regiser this manifest to application installing machine? Regards Joy
Anonymous
April 22, 2007
This summarize things up. Thank you! I had problems with "side by side configuration..." error on Vista, the problem was solved when I included following files: msvcp80.dll msvcr80.dll msvcm80.dll Microsoft.VC80.CRT.manifest in the same dir as the program executable. I first checked with depends.exe which version was used with my exe and included the proper manifest and dlls.
Anonymous
August 16, 2007
I am trying to run an application created with VS 2005 C/C++ on a machine that does not have VS 2005 installed on it. I used the information on files needed in Boris' April 23, 2007 posting, and copied the 3 dll's and the manifest file to the directory containing my application. That worked. Thanks Boris! Since it does not make sense to copy these 4 files into every directory with a VS 2005 C/C++ application, is there a way to make them available to all VS 2005 C/C++ applications in all directories?
Anonymous
August 21, 2007
I am trying to write an add-in DLL to extend the Mozilla Firefox browser, and am getting the R6034 "An application has made an attempt to load the C runtime library incorrectly" error when Firefox starts up with my DLL installed. My DLL has a manifest which correctly references the dependency on the Microsoft.VC80.CRT assembly. However the Firefox executable does not have a dependency on Microsoft.VC80.CRT, though it does have an embedded manifest, which appears to be correct. It appears that when my DLL is installed, Firefox tries the load the VC8 runtime when it starts up, which of course produces the R6034 error. Does anyone have any suggestions as to what to do here? If I put an external firefox.exe.manifest file into the folder where the firefox.exe executable resides, the error goes away, but I can't do that when redistributing my DLL. I also have no control over the Firefox executable. So what can I do in this scenario, where I have a DLL that depends on the Microsoft.VC80.CRT assembly (and which has a correct manifest that reflects that), but which is being used by an executable (Firefox, over which I have no control) that doesn't have the VC80 runtime dependency, and whose embedded manifest does not refer to Microsoft.VC80.CRT?
Anonymous
November 01, 2007
Thank you! In my case helps copying files for release version: msvcr80.dll Microsoft.VC80.CRT.manifest of files for debug version: msvcr80d.dll Microsoft.VC80.DebugCRT.manifest It was very complicated to find out this moment.
Anonymous
February 27, 2008
Thank you very much for such an informative post. Here is the problem that I am trying to resolve: I have built an MFC application which uses Office 2007 automation and emits an Excel spread sheet, however, I cannot install office on the target machine so I am trying to embed Excel as resouces in my app. So far I have succeeded to embed but when I try to run Excel which is detached as an .exe from my application. I have tried to isolate all the dependencies but I still get weired behavior and get R6304 message. I also profile the working Excel.exe through dependency walker and then my detached exe and found differences. Here is a partial log from the problem .exe: 00:00:00.641: GetProcAddress(0x7C800000 [c:windowssystem32KERNEL32.DLL], "FindActCtxSectionStringW") called from "c:developmentautoprojectautoprojectMSVCR80.DLL" at address 0x78131DBE and returned 0x7C82FD4C by thread 1. 00:00:00.656: LoadLibraryA("USER32.DLL") called from "c:developmentautoprojectautoprojectMSVCR80.DLL" at address 0x781396ED by thread 1. 00:00:00.656: LoadLibraryA("USER32.DLL") returned 0x7E410000 by thread 1. 00:00:00.656: GetProcAddress(0x7E410000 [c:windowssystem32USER32.DLL], "MessageBoxA") called from "c:developmentautoprojectautoprojectMSVCR80.DLL" at address 0x78139705 and returned 0x7E45058A by thread 1. 00:00:00.656: GetProcAddress(0x7E410000 [c:windowssystem32USER32.DLL], "GetActiveWindow") called from "c:developmentautoprojectautoprojectMSVCR80.DLL" at address 0x78139722 and returned 0x7E41D658 by thread 1. 00:00:00.656: GetProcAddress(0x7E410000 [c:windowssystem32USER32.DLL], "GetLastActivePopup") called from "c:developmentautoprojectautoprojectMSVCR80.DLL" at address 0x78139737 and returned 0x7E43153A by thread 1. 00:00:00.656: GetProcAddress(0x7E410000 [c:windowssystem32USER32.DLL], "GetUserObjectInformationA") called from "c:developmentautoprojectautoprojectMSVCR80.DLL" at address 0x7813976C and returned 0x7E4312C0 by thread 1. 00:00:00.656: GetProcAddress(0x7E410000 [c:windowssystem32USER32.DLL], "GetProcessWindowStation") called from "c:developmentautoprojectautoprojectMSVCR80.DLL" at address 0x78139784 and returned 0x7E419195 by thread 1. 00:00:00.656: LoadLibraryExW("C:WINDOWSsystem32uxtheme.dll", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) called from "c:windowssystem32USER32.DLL" at address 0x7E42DBFB by thread 1. 00:00:00.672: Loaded "c:windowssystem32UXTHEME.DLL" at address 0x5AD70000 by thread 1. Successfully hooked module. 00:00:00.672: DllMain(0x5AD70000, DLL_PROCESS_ATTACH, 0x00000000) in "c:windowssystem32UXTHEME.DLL" called by thread 1. 00:00:00.672: DllMain(0x5AD70000, DLL_PROCESS_ATTACH, 0x00000000) in "c:windowssystem32UXTHEME.DLL" returned 1 (0x1) by thread 1. 00:00:00.672: LoadLibraryExW("C:WINDOWSsystem32uxtheme.dll", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned 0x5AD70000 by thread 1. 00:00:00.672: LoadLibraryW("uxtheme.dll") called from "c:windowssystem32UXTHEME.DLL" at address 0x5AD7B2C4 by thread 1. 00:00:00.672: LoadLibraryW("uxtheme.dll") returned 0x5AD70000 by thread 1. 00:00:00.672: LoadLibraryExW("C:WINDOWSsystem32MSCTF.dll", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) called from "c:windowssystem32USER32.DLL" at address 0x7E42DBFB by thread 1. 00:00:00.688: Loaded "c:windowssystem32MSCTF.DLL" at address 0x74720000 by thread 1. Successfully hooked module. Here is a partial log from good .exe following the same sequence upto this point: 0:00:01.203: GetProcAddress(0x7C800000 [c:windowssystem32KERNEL32.DLL], "FindActCtxSectionStringW") called from "c:windowswinsxsx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700MSVCR80.DLL" at address 0x78131DBE and returned 0x7C82FD4C by thread 1. 00:00:01.219: GetProcAddress(0x7C800000 [c:windowssystem32KERNEL32.DLL], "GetSystemWindowsDirectoryW") called from "c:windowswinsxsx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700MSVCR80.DLL" at address 0x78131F1A and returned 0x7C80AD29 by thread 1. 00:00:01.219: DllMain(0x78130000, DLL_PROCESS_ATTACH, 0x0013FD30) in "c:windowswinsxsx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700MSVCR80.DLL" returned 1 (0x1) by thread 1. 00:00:01.219: DllMain(0x73000000, DLL_PROCESS_ATTACH, 0x0013FD30) in "c:windowssystem32WINSPOOL.DRV" called by thread 1. 00:00:01.219: DllMain(0x73000000, DLL_PROCESS_ATTACH, 0x0013FD30) in "c:windowssystem32WINSPOOL.DRV" returned 1 (0x1) by thread 1. 00:00:01.219: DllMain(0x3A9D0000, DLL_PROCESS_ATTACH, 0x0013FD30) in "c:program filesmicrosoft officeoffice12OART.DLL" called by thread 1. 00:00:01.219: GetProcAddress(0x7C800000 [c:windowssystem32KERNEL32.DLL], "HeapSetInformation") called from "c:program filesmicrosoft officeoffice12OART.DLL" at address 0x3A9D1781 and returned 0x7C839469 by thread 1. 00:00:01.250: DllMain(0x3A9D0000, DLL_PROCESS_ATTACH, 0x0013FD30) in "c:program filesmicrosoft officeoffice12OART.DLL" returned 1 (0x1) by thread 1. 00:00:01.250: DllMain(0x77120000, DLL_PROCESS_ATTACH, 0x0013FD30) in "c:windowssystem32OLEAUT32.DLL" called by thread 1. 00:00:01.250: DllMain(0x77120000, DLL_PROCESS_ATTACH, 0x0013FD30) in "c:windowssystem32OLEAUT32.DLL" returned 1 (0x1) by thread 1. 00:00:01.250: Unloaded "c:windowssystem32SHIMENG.DLL" at address 0x5CB70000 by thread 1. 00:00:01.250: GetProcAddress(0x7C800000 [c:windowssystem32KERNEL32.DLL], "HeapSetInformation") called from "c:program filesmicrosoft officeoffice12EXCEL.EXE" at address 0x30002F1E and returned 0x7C839469 by thread 1. 00:00:01.281: LoadLibraryW("C:Program FilesCommon FilesMicrosoft Sharedoffice12mso.dll") called from "c:program filesmicrosoft officeoffice12EXCEL.EXE" at address 0x30004BC2 by thread 1. 00:00:01.297: Loaded "c:program filescommon filesmicrosoft sharedoffice12MSO.DLL" at address 0x32600000 by thread 1. Successfully hooked module. 00:00:01.328: Loaded "c:windowssystem32MSI.DLL" at address 0x745E0000 by thread 1. Successfully hooked module. Can't figure out why the dll is behaving differently it is the same dll in winsxs which i have copied from into the app dir for self-contained deployment together with the manifest file. Any help in this respect will be greatly appreciated. Thanks Afshan
Anonymous
July 24, 2008
I tried placing both the manifest files

x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.manifest
x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_3bf8fa05.manifest and the required 6 dlls in the application folder, but still my application CANNOT RUN on the system on which visual studio is not installed . Can anyone please help me? Thanks in Advance.

Anonymous
August 24, 2008
How do we force an application (say sample.exe or sample.dll) to look for dependent CRT libraries in WinSxS directory? I have an application which registers itself with the windows when it is installed. I am getting R6034 error when it tries to register. I looked into the manifest file and it seems alright. The application is built in Vs2008 and this behavior is seen when I am trying to migrate my solution files from vs2003 to vs2008. Thanks in advance.
Anonymous
January 20, 2009
Dependancy Walker may also show a more specific error message. In my case it was this: Error: The Side-by-Side configuration information in "<snip>.EXE" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001). Which pointed me to the .config file and the fact that somehow I had a ” character instead of a " character. I don't know why that more specific error message couldn't be displayed at the command prompt.
Anonymous
February 03, 2009
Is there another way to fix that, except of installing the Microsoft Visual C++ 200x SP1 Redistributalbe Package (x86)? Or copying the needed dlls in the folder of the executable? Perhaps a setting in MSVC to include this dlls in the executable? thx
Anonymous
November 01, 2009
I checked the function static BOOL __cdecl _check_manifest(HMODULE hDllHandle) this function returns the error for dll "msvcr90.dll" at following check /* check condition (4) */ { ACTCTX_SECTION_KEYED_DATA askd = { sizeof(askd) }; if (!(pfnFindActCtxSectionStringW)(0, NULL, ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION, _CRT_DLL_FILENAME, &askd)) { / no activation context used to load CRT DLL, means no manifest present in the process */ return FALSE; } } the case 4 is (4) if (!(loaded through a manifest)) * return FALSE; the VS and MFC dll's like mfc90.dll, mfc90d.dll ,msvcr90.dll, msvcr90d.dll , msvcp90.dll, msvcp90d.dll are in the application directory. is this incorrect? here r some my questions 1] why the app loads msvcr90.dll instead of msvcr90d.dll as my app is running in debug mode 2] when I open the debug exe from VS2008 it shows that it contains the manifest, then why the function returns false waiting for reply

次の方法で共有

How to Debug 'The System cannot Execute the specified program' message.

Comments

その他のリソース