【发布时间】：2015-10-06 17:08:47
【问题描述】：
我在共享网络驱动器上有一个 32 位 C++ 可执行文件。我在这个网络上有一堆 64 位 Windows 7 Professional PC。他们中的一些人运行我的程序很好，其他人产生“应用程序无法正确启动（0xc000007b）”错误。
在阅读了 SO 问题 The application was unable to start correctly (0xc000007b) 和其他类似的问题后，我安装了 Dependency Walker。
Dependency Walker 将 2 个 DLL - MSVCP120D.Dll 和 MSVCR120D.DLL - 在依赖树中识别为 64 位。但是这两个 DLL 都与可执行文件位于同一目录中。 （那么为什么程序可以在任何 PC 上运行？！）使用 /headers 选项运行 dumpbin 确认它们是 64 位的。
这些 DLL 与 Visual Studio 2013 一起分发，因此我将新的 DLL 从那里复制到我的文件夹中。 Dumpbin /headers 将新的标识为“1C4”，而不是像以前的那样是 x64。 Dependency Walker 不再将它们标记为 64 位，但它仍然说“找到了具有不同 CPU 类型的模块”，并且在这些 DLL 的详细分解中，它用红色将它们标记为“452”，而不是 x86。该程序在同一台 PC 上仍然失败并显示 (0xc000007b)。
什么是 452（= 十六进制 1C4）CPU，如何获得这些 DLL 的真正 x86 版本？
【问题讨论】：
-
从程序目录中删除 DLL 并从 MS 网站运行 the Visual C++ Redistributable Runtime package。
-
@Ben Voigt 好的，我做到了。 Redistributable Package 报告“安装成功” 我删除了所有以“ms”开头的本地 DLL - 还有其他特定于应用程序的 DLL。我仍然在同一台机器上收到 7B 错误。确实，它运行没有问题的机器都是过去安装了 Visual Studio 的机器。
-
@Hans Passant - 抱歉，这不是错字。它确实说 1C4 并且 Dependency Walker 说 452（十六进制的 1C4 是十进制的）。我模糊地记得这是 ARM 处理器的代码，但我在网上找不到任何确认信息，也不知道为什么我的 PC 上应该有 ARM DLL。
-
最重要的是汉斯所说的——“不要部署调试版本”。如果可执行文件正在加载任何以 D 结尾的 DLL，则说明您构建错误。 （但是，如果你只是在内部使用它，它实际上可能并不违法。）