如何检查哪个模块导致 LINK1112 错误？答案

【问题标题】：How do I check which module causes LINK1112 error?如何检查哪个模块导致 LINK1112 错误？
【发布时间】：2015-04-07 15:12:56
【问题描述】：

有没有办法告诉编译时使用的每个 DLL 的完整路径？

我正在尝试制作一个带有易于编组函数的 DLL，以便在 C# 应用程序和文件系统 Minifilter 之间进行通信（目前使用 Minispy 示例来检查一切是否运行顺利）。

在 Visual Studio 2013 中使用“Win32”作为我的目标平台时成功编译和运行，但使用 printf("%p",...); 打印出指针时它们的长度只有 8 个字符，而本来应该是 16 个字符（我的计算机是 64 位），这让未来的指针杂乱无章。

对于其他项目，我的活动解决方案平台一直是 x64。不幸的是，将配置管理器中的平台更改为 DLL 的 x64 会在编译期间生成以下错误：

错误 1 错误 LNK1112：模块机器类型“X86”与目标机器类型“x64”冲突

我在网上查了一下，这似乎是解决方案某些部分的配置问题，但我所有的项目都应该在 x64 中编译。清理和重建以删除旧文件也没有效果。

我已使用 dumpbin.exe 检查我认为我的库链接到的 DLL 的机器类型，并且一切似乎都井然有序。我通过检查项目属性中的链接器命令行选项得到了这些，但它们的名称没有显示它们是从哪里读取的（例如：kernel32.lib; user32.lib; gdi32.lib; fltLib.lib ...）。由于我仍然遇到此问题，我认为它可能链接到相同 DLL 的错误（32 位）版本。

有没有办法告诉编译时使用的每个 DLL 的完整路径？或者更好的是，有没有办法知道具体是哪个 DLL 导致了 LINK1112 错误？

我使用了 /VERBOSE:LIB 命令并删除了 /NOLOGO 选项，但输出效果不佳，在要执行的命令后立即停止，没有其他信息。

【问题讨论】：

使用 /VERBOSE 并在输出中搜索 LNK1112。它应该让你找到罪魁祸首。

标签： c++ c visual-studio linker

【解决方案1】：

我应该在几个月前解决这个问题时回答这个问题，但我忘了我把它贴在这里了。但我会试着回忆我做了什么。

最后，如果我没记错的话，我很确定拯救我的是在成功编译的 (x86) 库上使用 Dependency Walker。我以前使用过它，但我在错误的模式下运行它（x64 或 x86），使用正确的模式会发现 x64 架构缺少模块。

【讨论】：