应用程序无法正确启动(0xc000007b)

通常我们会得到 0xC000007B错误代码(也就是 STATUS_INVALID_IMAGE_FORMAT) ，如果:

• 如果一个32位的应用程序试图加载一个64位的 DLL。
• 或者如果一个64位的应用程序试图加载一个32位的 DLL。
• 或者，如果一个64位的应用程序试图在32位的 Windows 上运行。

为了真正了解，我建议使用 依赖性 Walker测试应用程序及其依赖项之间是否存在问题

注意 ，所有你需要做的就是使用这个工具打开你的应用程序，问题会以红色日志条目的形式出现在屏幕底部。

(至少在撰写本报告时，即2022年)

另外，请确保您运行了正确的 Dependency Walker 版本，例如，x86版本在打开 x64二进制文件时将显示不正确的结果。

无法解决加载时依赖性。最简单的调试方法是使用 依赖 Walker。使用 Profile 选项获取加载过程的诊断输出。这将确定故障点，并应指导您找到解决方案。

此错误的最常见原因是试图将64位 DLL 加载到32位进程中，或者相反。

在这种情况下，调试器可能是有用的。基本上，如果你遵循 这里有说明，你可以运行两个 IDE，一个将调试到另一个。如果在其中运行应用程序，有时可能会捕获错过的错误。值得一试。

这是一个丢失的 dll。 可能的情况是，使用 com 端口的 dll 具有未解析的 dll 依赖性。 可以使用依赖关系遍历器和 Windows 调试器。例如，检查所有的 mfc 库。另外，您还可以使用 nrCommlib-它是使用 com 端口的很好的组件。

我最近遇到了一个问题，我正在开发一个应用程序(使用串行端口) ，它可以在我测试的所有机器上工作，但是一些人得到了这个错误。

发生错误的所有机器都在运行 Win7x64，而且从未更新过。

在我的特殊情况下，运行 Windows 更新修复了所有的机器。

我见过在一台没有安装 Visual C + + 的机器上运行 VC + + 调试可执行文件时出现的错误。构建一个发布版本并使用它来修复它。

刚刚为我的个人项目解决了这个问题(感谢 Dries)。对我来说，这是因为项目路径太长。在拯救了。Sln 转换为一个更短的路径(C:/MyProjects) ，然后从那里编译它，不会出现错误。

实际上，这个错误表明图像格式无效。但是，为什么会发生这种情况，错误代码通常意味着什么？实际上，当您试图运行一个为64位 Windows 操作系统而设计或打算使用该操作系统的程序，但您的计算机运行在32位操作系统上时，可能会出现这种情况。

可能的原因:

• Microsoft Visual C + +
• 需要重新启动
• X 指挥部
• .NET 框架
• 需要重新安装
• 需要以管理员身份运行应用程序

资料来源: http://www.solveinweb.com/solved-the-application-was-unable-to-start-correctly-0xc000007b-click-ok-to-close-the-application/

我尝试了这里指定的所有方法，找到了另一个答案。我必须用32位 DLL 编译我的应用程序。我已经用32位和64位构建了库，但是将 PATH设置为64位库。在我重新编译了我的应用程序之后(我的代码也发生了一些变化) ，我得到了这个可怕的错误，并且纠结了两天。最后，在尝试了许多其他方法之后，我将 PATH改为在64位 DLL 之前使用32位 DLL (它们具有相同的名称)。而且成功了。我只是把它添加到这里，以便完整。

还要下载并将“ Dependency”解压缩到放置 wget.exe 文件夹的同一文件夹中

Http://gnuwin32.sourceforge.net/packages/wget.htm

然后，在同一个文件夹中会有一些 lib * . dll 文件和 wget.exe 文件，它应该可以正常工作。

(我也在这里回答了我最初发现的 https://superuser.com/a/873531/146668。)

我在使用 MicrosoftVisualStudio2012开发客户机-服务器应用程序时遇到过同样的问题。

如果您使用 Visual Studio 开发应用程序，则必须确保新的(即未在其上开发软件的计算机)具有适当的 Microsoft Visual C + + 可再发行包。根据需要，您需要 Visual C + + 可再发行包的正确年份和位版本(即32位的 x86和64位的 x64)。

VisualC + + 可再发行包安装运行时组件，这些组件是运行使用 VisualStudio 生成的 C + + 应用程序所必需的。

这里有一个到 针对 VisualStudio2015的 VisualC + + 可再发行版的链接。

你可以通过控制面板-> 程序-> 程序和特性来检查安装了哪些版本。

下面是我如何得到这个错误并修正它:

1)我在自己的电脑上使用 VisualStudio2012开发了一个32位的应用程序。 我们把我的电脑叫做计算机 A。

2)我把.exe 和相关文件安装在另一台我们称之为 ComputerB 的计算机上。

3)在 ComputerB 上，我运行.exe 并得到错误消息。

4)在 ComputerB 上，我查看了程序和特性，没有看到 Visual C + + 2012 Redistribution (x64)。

5)在 ComputerB 上，我在谷歌上搜索了 Visual C + + 2012 Redistribution，选择并安装了 x64版本。

6)在 ComputerB 上，我在 ComputerB 上运行.exe，没有收到错误消息。

在前面的答案中已经提到，使用依赖关系遍历器是正确的方法，在我的例子中(我的应用程序一直因为错误代码而失败) ，依赖关系遍历器显示了一些不相关的 dll！

最后发现我可以通过“配置文件”菜单运行分析，它会运行应用程序，并停止在确切的 dll 造成的问题！我发现一个32位 dll 被挑选，因为路径和固定它。

在我的例子中，错误发生在我在构建一个 DLL (使用 Visual Studio 2015)之后重命名它时，因此它符合依赖于 DLL 的可执行文件所期望的名称。重命名后，Dependency Walker 显示的导出符号列表为空，并显示“应用程序无法正确启动”的错误消息。

因此，可以通过更改 VisualStudio 链接器选项中的输出文件名来修复它。

我刚好碰到这个问题。我在 Windows 10控制面板的“应用程序和功能”下搜索“ C + +”，注意到某种更新在几天前刚刚运行，并安装了 VC + + 可再发行版2012-2017。运行到错误消息的应用程序只需要 VC + + 2010。我卸载了所有这些应用程序，然后只重新安装了2010 x86/x64，错误消失了，应用程序正常运行。

如果由于某种原因从 x64计算机加载 x86资源，就会发生这种情况。为了明确避免这种情况，将这个预处理器指令添加到 stdafx.h (当然，在我的示例中，有问题的资源是 Windows Common Controls DLL。

#if defined(_WIN64)
#pragma comment(linker, "\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df'\"")
#endif

如果您试图显示应用程序具有依赖于 微软。视窗。公共控件程序集的依赖项，则可以具有此属性。如果要加载公共控件库的版本6，则执行此操作，以便将视觉样式应用于公共控件。

你可能从 Windows XP 时代就开始使用微软的原始文档，并在你的应用程序清单中添加了以下内容:

<!-- Dependancy on Common Controls version 6 -->
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"/>
</dependentAssembly>
</dependency>

Windows XP 不再是操作系统，你也不再是一个32位应用程序。在中间的17年 微软更新了他们的文档; 现在是你更新你的清单的时候了:

<!-- Dependancy on Common Controls version 6 -->
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"/>
</dependentAssembly>
</dependency>

Raymond Chen 在公共控制方面有一段可爱的历史:

• WindowsXP 通用控件 < em > (存档)的历史记录

您的系统上可能有多个版本的 dll。你可以搜索你的系统来找出答案。这个问题可以通过简单地更改路径中目录的顺序来解决。这是我的问题。(无法在 Qt 之外运行 Qt Creator GUI。“应用程序无法正确启动(0xc000007b)”错误)

当然，主要的问题是 DLL 文件丢失了，或者更有可能是损坏了。如果是这种情况，那么我有一些非常好的想法(特别是如果您已经手动下载并安装了 DLL!)...

TLDR: 删除所有手动复制/粘贴的 DLL，卸载旧的可重新发布的安装，并为 都有32位和64位安装重新安装新的可重新发布的 DLL。

怎么做

这种将丢失的 DLL 复制/粘贴到 system32等等的解决方案，自从我记得在20世纪90年代以来就一直有效，但现在似乎不再有效了(2020年)。因此，如果你最近遇到这个问题，我建议:

• 在 windows\system32和 windows\SysWOW64中，删除操作系统允许您作为管理员删除的所有匹配 ms*.dll的文件。
• 卸载 Windows 中所有的 VisualC + + 可重新发布版本。这样可以防止“你已经拥有了这个!”对话显示在重新安装时，详细说明在下一步，当我们重新安装。
• 从定期可用的下载站点重新安装2015-2019 VisualC + + 可重新发行版。如果这不工作，下载和安装其他人，但个人来说，2015-2019年涵盖了我的一切。不管您的机器是什么，< strong > 都安装 x32和 x64软件包! (所有下载链接: 收集 VC + + 下载链接; MSVCR120.dll 修正; MFC140U.dll 修正.)

你怎么知道它起作用了

有很多程序员经历过这种情况，所以，有一个单一的，可能的解决方案的想法经常被抛弃，但是让我们积极一点！

• 如果删除匹配的 ms*.dll文件工作，那么您将不再得到关于 error code 0xc000007b的错误。相反，您将收到一条关于丢失 .dll的消息。这告诉您您正在找到正确的代码路径！
• 如果安装可再发行的作品，那么某些流行的，DLL 文件应该出现在上述 system32和 SysWO64文件夹。例如: MSVCR120.dll、 MSVCR140.dll、 MSVCR100.dll、 MSVCP100.dll、 MSVCP120.dll、 MSVCP140.dll和朋友。

最后，可能的最佳机会

有时事情不按计划进行(我们在 Windows 世界中都知道)。您也可以尝试以下方法！

• 在 Windows 中打开“打开或关闭 Windows 特性”选项卡(在 Windows8-10中支持)。取消检查 .NET Framework安装。你会看到一个小装置经过。
• 重启系统。再次转到上面的特性，重新检查 .NET Framework，然后单击“ ok”。如果这个工作，您将看到一个“安装和更新。NET 框架”消息，可能需要一分钟左右的时间。完成此操作后，我建议再次重启。

祝你好运！

在从存储库获取代码并在新机器上编译时，我遇到了这个问题。复制整个存储库，然后进行编译，最终生成一个可执行文件。结果发现一个32位 DLL 意外地没有被签入。作为上述状态的人，使用“依赖获取器”来找出问题出在哪里。

为了更清楚地查看下面的屏幕截图，在后台，exe 试图加载错误的 DLL (注意’64’) ，导致“应用程序无法正确启动0xc0007b”，在前台，exe 被简单地复制过来(其中包括正确的 DLL)。

我来这里时，我正在寻找: “ Golang 视窗(0xc00007b)”

我有一个在 Golang 编写的应用程序，它使用 iconv。它能在我的机器上工作，但不能在别人的机器上。

第一个错误是 丢失的 DLL: libiconv-2. DLL所以我猜他们是从网上下载的但是是32位版本而不是64位版本所以是 出现了0xc00007b 错误。

我搜索了我的系统上的 DLL，但我没有成功，直到我搜索 MinGW64路径，在我的情况下是: C:\msys64\mingw64\bin

解决方案是使用. exe 分发 DLL，该文件夹位于 MinGW 文件夹中。