更新：这基本上都是虚假的。事实证明，运行应用程序的机器上的Depends.exe版本是32位版本。修复后，两个机器将系统DLL显示为64位，因此这不是问题的根源。不确定为什么依赖会在32位exe中以这种方式显示它们。
进一步更新：最终问题是一个64位DLL。使用正确版本的Dependency Walker后，这更容易找到。选择32对64位版本并不基于您运行的平台。来自FAQ：
Dependency Walker适用于任何32位或64位Windows模块。 有32位和64位版本的Dependency Walker。所有版本 能够或打开32位和64位模块。但是，有 使用32位Dependency Walker进行处理的主要优点 32位模块和64位Dependency Walker处理64位 模块。在64位版本上运行时尤其如此 Windows，允许执行32位和64位程序。 64位Windows上的32位子系统（称为“WOW64”）有自己的子系统 私人注册表，“AppPaths”，“KnownDlls”，系统文件夹和 清单处理。只有32位版本的Dependency Walker才能 访问这个32位环境，这是准确处理所需的 一个32位模块。同样，只有64位版本的Dependency Walker可以完全访问64位环境，因此应该始终如此 用于处理64位模块。
我有一个应用程序可以在一台机器上正确构建而在另一台机器上构建不正确。两者都是通过BootCamp运行Windows 7的MacBook Pro。它们是通过QtCreator构建的，VS2010是编译/链接工具。
在机器A上，它编译和链接没有任何报告的错误。但是，运行时失败并出现0xc000007b错误（STATUS_INVALID_IMAGE_FORMAT）。 Depends.exe确认exe是32位exe，但所有Windows DLL（advapi32.dll等）都链接为64位DLL。看起来这似乎是一个链接时间错误，但显然不是。
在机器B上，一切都编译并正确运行。 Depends.exe确认exe和所有链接的DLL都是32位。
我的Qt项目配置如下：
qmake: qmake.exe PROJECT.pro -r -spec win32-msvc2010 "CONFIG+=declarative_debug"
我相信-spec win32-msvc2010部分足以指定32位构建。
项目文件显式链接到位于以下位置的Windows导入lib文件： C：/ Program Files（x86）/ Microsoft SDKs / Windows / v7.0A / Lib 我已经确认这些是32位导入库。项目文件中的显式LIB + =行调用此路径。如果从项目文件中删除此行，则链接仍会成功。所以我不确定在这种情况下如何指定Windows系统导入库的位置。
我使用dumpbin验证导入.libs被标记为32位或64位。我们正在指定具有32个导入库的位置。
因为一台机器工作而另一台机器没有，我认为问题是机器配置问题。因此，我从机器A中删除并重新安装了MS工具：
按以下顺序重新安装以上所有内容：
我仍然得到一个与64位DLL链接的32位exe。
什么可能导致奇怪的链接？和/或如何更准确地确定它认为应该链接到64位DLL的原因？
答案 0 :(得分：1)
不是。
问题文本的答案：
这完全是虚假的。原来是Depends.exe的版本 在应用程序运行的机器上是32位版本。上 修复，两台机器都将系统DLL显示为64位，这样就可以了 不是问题的根源。
最终问题是一个64位DLL。这更容易找到 使用正确版本的Dependency Walker之后。选择32 vs 64位版本不基于您运行的平台。从 FAQ：
Dependency Walker适用于任何32位或64位Windows模块。 有32位和64位版本的Dependency Walker。所有版本 能够或打开32位和64位模块。但是，有 使用32位Dependency Walker进行处理的主要优点 32位模块和64位Dependency Walker处理64位 模块。在64位版本上运行时尤其如此 Windows，允许执行32位和64位程序。 64位Windows上的32位子系统（称为“WOW64”）有自己的子系统 私人注册表，“AppPaths”，“KnownDlls”，系统文件夹和 清单处理。只有32位版本的Dependency Walker才能 访问这个32位环境，这是准确处理所需的 一个32位模块。同样，只有64位版本的Dependency Walker可以完全访问64位环境，因此应该始终如此 用于处理64位模块。