c++ - LoadLibrary貌似加载错误的DLL

Question

我在使用 Windows 上的 LoadLibrary 时遇到了一个奇怪的问题。首先是一些背景。这个应用程序依赖于 Qt，而 Qt 被拆分成几个库。我正在尝试升级 Qt 的版本，但不会破坏任何人。较新的 Qt 库向后兼容旧的。这意味着如果加载新版本，则使用旧版本构建的应用程序可以运行。反之则不然——如果加载旧版本，使用新版本构建的应用程序将缺少符号。

Qt DLL 位于特定于版本的目录中(比如 c:\qt\qt-4.5.2\lib 和 c:\qt\qt-4.8.1\lib作为示例)。大多数开发人员在他们的 PATH 中还有一个公共(public)目录，其中包含我们使用的所有第三方库的“当前”版本(称为 c:\common\lib)。这是运行应用程序时通常可以找到 Qt 库的地方。

我将新的 Qt 版本库放在公共(public)位置，除了一种情况外，一切似乎都运行正常。有问题的应用程序被分成多个库，其中一些库是通过调用 LoadLibrary() 加载的。其中一些运行时加载的 DLL 依赖于 Qt 库。在一种情况下，加载的 DLL 依赖于 QtXml，它本身依赖于 QtCore。

这就是它变得奇怪的地方。一个应用程序依赖于 QtCore 并且还加载了一个依赖于 QtXml 的库。该应用程序和库是与旧版本的 Qt 链接构建的。如果此应用程序仅使用 PATH 中的公共(public)目录运行，则一切正常，因为新的 Qt 版本 DLL 是从公共(public)目录加载的。但是，如果 PATH 包含在公共(public)目录之前存储旧 Qt 版本 DLL 的目录，则加载运行时 DLL 会失败并丢失符号。

(这种情况在进行自动化单元测试时会出现，脚本会显式设置 PATH 以使用特定的库版本。)

据我所知，应用程序正在加载旧版本的 QtCore.dll 并且运行时加载的 DLL 正在(以某种方式)加载新版本的 QtXml.dll，它失败了，因为已经加载的 QtCore 没有它需要的符号。

但这似乎是不可能的，因为 PATH 类似于 c:\qt\qt-4.5.2\lib;c:\common\lib(加上其他不相关的路径)。如果我从公共(public) lib 目录中删除较新的 QtXml(不是用旧版本替换它，只是删除它)，那么 LoadLibrary()成功，因为它加载了所有 Qt 库的 4.5.2 版本。但这不是一个好的长期解决方案，因为在 PATH(公共(public))中没有 Qt 特定版本目录的情况下运行将无法找到 QtXml。

怎么会这样？ LoadLibrary()(或它递归调用以解决库的依赖关系的任何东西)如何从 later 在 PATH 中加载库？我找不到任何表明对公共(public)库目录给予特殊考虑的信息(它不是设置的 DLL 目录)。它没有在构建过程中提及，它只是开发人员为了方便而在他们的 PATH 中拥有的东西。

顺便说一句，在 Linux 上存在类似的情况，使用 LD_LIBRARY_PATH 和 dlopen()，并且在那里工作得很好。这是 Windows 正在做的不同的事情，我不明白。有没有人知道可能出了什么问题？

Answer 1

LoadLibrary 有很多令人惊讶的行为。确保你完全理解了所有 Remarks在 MSDN 中找到它。

如果已经加载了同名的库(任何版本)，LoadLibrary 只会返回已加载 DLL 的句柄。这可能会在您的场景中发挥作用。

接下来，如果您指定了一个相对路径或只是一个文件名，LoadLibrary 应用 arcane search rules .您的 PATH 变量通常是最后搜索的地方。很可能其他一些规则甚至在检查 PATH 之前就找到了“错误的”DLL。一个好的准则是始终使用您要加载的文件的绝对路径，以确保其搜索规则不会抓取错误的文件。一个常见的安全漏洞是无法控制 LoadLibrary 搜索的位置，攻击者会诱使您的应用程序加载经过篡改的 DLL。

最后，安装程序可以应用 DLL redirection可以覆盖您的要求以及可能找到的位置。我不确定这对于 Qt DLL 是否常见，但您可能需要检查您的注册表。

我偶尔使用 ProcMon from SysInternals在加载 DLL 时观察程序。您可以看到它检查的每个地方，这可能会让您了解为什么它会找到错误的版本。