我有一个客户端/服务器应用程序，我一直在单台 PC 上开发它。现在它需要两个串口，所以我从朋友那里借了一台PC。
当我构建我的应用程序并尝试运行或调试它（无论是在 Delphi IDE 中还是从 Windows 文件管理器中）时，它会出错“应用程序无法正确启动（0xc000007b）”。
谷歌搜索并没有带来太多，但似乎表明这不是 Delphi 特有的，并且在其他应用程序中也会发生。这似乎是由从 64 位应用程序调用 32 位 DLL 引起的，反之亦然。
谁能给我一个关于如何追踪这个的提示？
首先，我建议使用dependency walker测试您的应用程序及其依赖项之间是否存在问题
无法解决加载时间相关性。调试它的最简单方法是使用Dependency Walker。使用 Profile 选项获取加载过程的诊断输出。这将确定故障点并指导您找到解决方案。
此错误的最常见原因是尝试将 64 位 DLL 加载到 32 位进程中，反之亦然。
我尝试了此处指定的所有内容，并找到了另一个答案。我必须用 32 位 DLL 编译我的应用程序。我已经构建了 32 位和 64 位的库，但我PATH的库设置为 64 位。在我重新编译了我的应用程序（我的代码也进行了一些更改）之后，我遇到了这个可怕的错误并苦苦挣扎了两天。最后，在尝试了许多其他事情之后，我PATH将 32 位 DLL 更改为 64 位 DLL 之前（它们具有相同的名称）。它奏效了。为了完整起见，我只是在这里添加它。
这是一个丢失的dll。可能，与 com 端口一起使用的 dll 具有未解决的 dll 依赖性。您可以使用依赖walker 和windows 调试器。例如，检查所有 mfc 库。此外，您可以使用 nrCommlib - 它是与 com 端口一起使用的绝佳组件。
在前面的答案中已经提到，使用依赖walker 是要走的路，在我的情况下（我的应用程序不断失败并显示错误代码），dependency walker 显示了一些不相关的dll！
最后发现我可以通过转到“配置文件”菜单来运行分析，它将运行应用程序并停止在导致问题的确切 dll 处！我发现由于路径而选择了一个 32 位 dll 并修复了它。
我在使用 Microsoft Visual Studio 2012 开发客户端-服务器应用程序时遇到了同样的问题。
如果您使用 Visual Studio 开发应用程序，则必须确保新的（即未开发该软件的计算机）具有适当的 Microsoft Visual C++ Redistributable Package。适当地，您需要 Visual C++ Redistributable Package 的正确年份和位版本（即 x86 用于 32 位，x64 用于 64 位）。
Visual C++ Redistributable Packages 安装运行使用 Visual Studio 构建的 C++ 应用程序所需的运行时组件。
这是Visual C++ Redistributable for Visual Studio 2015的链接。
您可以通过转到控制面板 -> 程序 -> 程序和功能来检查安装的版本。
这是我得到这个错误并修复它的方法：
1) 我在计算机上使用 Visual Studio 2012 开发了一个 32 位应用程序。我们称我的计算机为ComputerA。
2) 我将 .exe 和相关文件安装在另一台我们称为 ComputerB 的计算机上。
3) 在 ComputerB 上，我运行 .exe 并收到错误消息。
4) 在 ComputerB 上，我查看了 Programs and Features 并没有看到 Visual C++ 2012 Redistributable (x64)。
5) 在 ComputerB 上，我搜索了 Visual C++ 2012 Redistributable 并选择并安装了 x64 版本。
6) 在 ComputerB 上，我在 ComputerB 上运行 .exe 并没有收到错误消息。
我最近遇到了一个问题，我正在开发一个应用程序（使用串行端口），它在我测试过的所有机器上都可以工作，但是有几个人遇到了这个错误。
事实证明，发生错误的所有机器都在运行 Win7 x64 并且从未更新过一次。
在我的特殊情况下，运行 Windows 更新修复了所有机器。
实际上，此错误表明图像格式无效。但是，为什么会发生这种情况以及错误代码通常意味着什么？实际上，当您尝试运行为或打算与 64 位 Windows 操作系统一起使用的程序时，可能会出现这种情况，但您的计算机正在 32 位操作系统上运行。
可能的原因：
This may be a case where debugging the debugger might be useful. Essentially if you follow the instructions here you can run two ide's and one will debug into the other. If you un your application in one, you can sometimes catch errors that you otherwise miss. Its worth a try.
我看到了试图在没有安装 Visual C++ 的机器上运行 VC++ 调试可执行文件的错误。构建发布版本并使用它修复它。
如果您试图证明您的应用程序依赖于Microsoft.Windows.Common-Controls程序集，则可以使用它。当您想要加载第 6 版的通用控件库时，您可以执行此操作 - 以便将视觉样式应用于通用控件。
您可能从 Windows XP 时代开始遵循 Microsoft 的原始文档，并将以下内容添加到您的应用程序清单中：
<!-- 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 对 Common Controls 有一段美好的历史：
在我的情况下，当我在构建 DLL（使用 Visual Studio 2015）后重命名 DLL 时发生错误，以便它符合依赖于 DLL 的可执行文件所期望的名称。重命名后Dependency Walker显示的导出符号列表为空，并显示上述错误消息“应用程序无法正确启动”。
因此，可以通过更改 Visual Studio 链接器选项中的输出文件名来修复它。
当然，主要问题是 DLL 文件丢失了，或者更可能是损坏了。如果是这种情况，那么我有一些很好的想法（特别是如果您手动下载并安装了 DLL！）...
TLDR：删除您已完成的每个手动复制/粘贴的 DLL，卸载旧的可再发行组件，并为32 位和 64 位安装重新安装新的可再
该怎么办
自从我记得 1990 年代以来，这种将丢失的 DLL 复制/粘贴到system32等的解决方案曾经有效，但它似乎不再有效（2020 年）。所以如果你最近遇到这个问题，我建议：
windows\system32和windows\SysWOW64中，删除所有匹配的文件，ms*.dll操作系统将允许您以管理员身份删除。你怎么知道它在工作
遇到这种情况的编码人员有很多变化，因此，通常会放弃只有一个可能的解决方案的想法，但让我们保持积极态度！
ms*.dll文件有效，那么您将不再收到有关error code 0xc000007b. 相反，您会收到有关丢失的消息.dll。这告诉您您正在访问正确的代码路径！system32和SysWO64文件夹中。例如：MSVCR120.dll, MSVCR140.dll, MSVCR100.dll, MSVCP100.dll, MSVCP120.dll, MSVCP140.dll, 和朋友。最后，可能的最佳机会
有时事情不会按计划进行（正如我们在 Windows 世界中都知道的那样）。你也可以试试下面的！
.NET Framework安装。您会看到一个小型安装。.NET Framework，然后单击“确定”。如果这可行，您将看到“安装和更新 .NET 框架”消息，这可能需要一分钟左右的时间。完成后，我建议再次重新启动。祝你好运！
还将“依赖项”下载并解压缩到放置 wget.exe 的同一文件夹中
http://gnuwin32.sourceforge.net/packages/wget.htm
然后，您将在同一文件夹中拥有一些 lib*.dll 文件以及 wget.exe，它应该可以正常工作。
（我也在这里回答了我最初找到的https://superuser.com/a/873531/146668 。）
刚刚为我的个人项目解决了这个问题（感谢 Dries）。对我来说，这是因为项目路径太长了。将 .sln 保存到较短的路径 (C:/MyProjects) 并从那里编译后，它运行时没有错误。
我刚遇到这个问题。我在 Windows 10 控制面板的“应用程序和功能”下搜索“C++”，发现几天前刚刚运行了某种更新并安装了 VC++ Redistributable 2012-2017。运行到错误消息的应用程序只需要 VC++ 2010。我卸载了所有这些，然后重新安装了 2010 x86/x64，错误消失了，应用程序按预期运行。
您的系统上可能有多个版本的 dll。您可以搜索您的系统以找出答案。只需更改路径中目录的顺序即可解决此问题。这是我的问题。（无法在 Qt 之外运行 Qt Creator GUI。“应用程序无法正确启动（0xc000007b）”错误）
如果出于某种原因从 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
从我的存储库中获取代码并在新机器上编译时遇到了这个问题。复制整个存储库然后编译会生成一个可以运行的可执行文件。结果是一个 32 位 DLL 意外没有被签入。正如上面所说的那样，使用“Dependency Walker”来找出它出错的地方。
为了更清楚要查找的内容，请参见下面的屏幕截图，在后台，exe 尝试加载错误的 DLL（注意“64”），导致“应用程序无法正确启动 0xc00007b”，而在前台exe 被简单地复制过来（其中包括正确的 DLL）。
