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

最新推荐文章于 2024-08-07 14:12:54 发布

转载最新推荐文章于 2024-08-07 14:12:54 发布 · 500 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/taoxu0903/archive/2008/09/16/1292092.html

文章标签：

#python #c/c++

本文介绍了解决C/C++应用程序因依赖的Visual C++库未找到而无法加载的问题。通过检查依赖项walker、manifest文件及侧边组件安装状态等步骤来定位并解决问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

[转载自：http://blogs.msdn.com/nikolad/articles/427101.aspx][http://msdn.microsoft.com/en-us/library/ms235342(VS.80).aspx]

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 http://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. Ceck 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

转载于:https://www.cnblogs.com/taoxu0903/archive/2008/09/16/1292092.html