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

本文介绍了解决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.

  1. 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.
  2. 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. 

  1. 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.
  2. 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.
  3. 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.
  4. 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: 

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

 <dependency>

    <dependentAssembly>

      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50215.4631" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

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

<!-- Copyright © 1981-2001 Microsoft Corporation -->

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

      <noInheritable/>

      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50215.4631" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>

      <file name="msvcr80.dll" hash="3ca5156e8212449db6c622c3d10f37d9adb12c66" hashalg="SHA1"/>

      <file name="msvcp80.dll" hash="92cf8a9bb066aea821d324ca4695c69e55b27cff" hashalg="SHA1"/>

      <file name="msvcm80.dll" hash="7daa93e1195940502491c987ff372190bf199395" hashalg="SHA1"/>

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

<!-- Copyright © 1981-2001 Microsoft Corporation -->

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

       <assemblyIdentity type="win32-policy" name="policy.8.0.Microsoft.VC80.CRT" version="8.0.50215.4631" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>

      <dependency>

            <dependentAssembly>

                  <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>

                  <bindingRedirect oldVersion="8.0.41204.256" newVersion="8.0.50215.4631"/>

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

### 问题分析与解决方案 在 VSCode 中遇到 `'The system cannot find the file specified'` 的错误,通常是因为以下原因之一:环境变量配置不正确、文件路径错误、工具链未正确安装或配置、VSCode 配置文件(如 `launch.json`)设置不当等。以下是详细的解决方法: --- #### 1. **检查环境变量** 确保系统环境变量中包含所需的工具链路径。例如,如果需要使用 Android SDK 或 Makefile 工具链,则需要确认这些工具已正确安装,并且其路径已添加到系统的 `PATH` 环境变量中[^1]。 - 在 Windows 系统中,可以通过以下步骤检查和修改环境变量: - 打开“系统属性” -> “高级系统设置” -> “环境变量”。 - 在“系统变量”部分找到 `Path`,点击“编辑”。 - 确保添加了工具链的安装路径(如 Android SDK 的路径或 Makefile 工具链路径)。 --- #### 2. **验证工具链是否正确安装** 如果系统提示找不到特定文件,可能是因为相关工具链未正确安装。例如,Android SDK 或者 Makefile 工具链可能没有正确配置。可以尝试重新安装或更新工具链,并确保安装路径已被正确引用。 - 对于 Android SDK,可以下载并安装最新版本的 Android Studio,然后通过其内置的 SDK Manager 安装所需的组件[^1]。 - 对于 Makefile,确保已安装 GNU Make 工具,并将其路径添加到环境变量中[^2]。 --- #### 3. **检查 VSCode 配置文件** VSCode 的调试配置文件 `launch.json` 是导致该问题的常见原因。如果配置文件中指定了错误的路径或目标文件,则会触发 `'The system cannot find the file specified'` 错误。以下是检查和修复 `launch.json` 的步骤: - 打开 `.vscode/launch.json` 文件,确保以下字段配置正确: ```json { "version": "0.2.0", "configurations": [ { "name": "C/C++: g++.exe build and debug active file", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/your_program_name.exe", // 确保此路径正确 "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": true, "MIMode": "gdb", "miDebuggerPath": "C:/path/to/gdb.exe", // 确保 gdb 路径正确 "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "C/C++: g++.exe build active file" } ] } ``` - 确保 `program` 字段指向正确的可执行文件路径。 - 确保 `miDebuggerPath` 指向正确的 GDB 或其他调试器路径。 --- #### 4. **重装 VSCode** 如果以上方法无效,可以尝试卸载并重新安装 VSCode。根据已有信息,重装 VSCode 不会影响当前的设置、扩展或文件记录[^4]。此外,重装后可以确保所有依赖项和配置文件被正确初始化。 --- #### 5. **调试错误消息** 如果问题仍然存在,可以参考调试指南来进一步分析错误消息 `'The system cannot execute the specified program'`。通常,这类错误可能是由于程序依赖的动态链接库(DLL)缺失或路径错误引起的[^3]。可以通过以下方法排查: - 使用工具如 Dependency Walker 检查程序依赖的 DLL 是否完整。 - 确保所有依赖的 DLL 文件位于程序运行路径或系统 `PATH` 中。 --- ### 示例代码:验证环境变量 以下是一个简单的批处理脚本,用于验证系统环境变量中是否包含指定路径: ```batch @echo off echo Checking PATH environment variable... echo %PATH% | findstr /C:"C:\path\to\your\toolchain" >nul if errorlevel 1 ( echo Toolchain path not found in PATH. ) else ( echo Toolchain path found in PATH. ) pause ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值