Question

从我对MSDN documentation的阅读中，我认为（在该基本名称的dll尚未加载的情况下）将完全限定的绝对文件名传递给LoadLibraryExW只会查看该路径。

E.g。（并注意这是正确的CSIDL_SYSTEM路径，如果这有所不同）

LoadLibraryExW (L"C:\\Windows\\System32\\foobar.dll", LOAD_LIBRARY_AS_DATAFILE);

如果该位置不存在该文件，

将失败。但是我得到了有趣的结果，让我觉得它在Windows 8.1上使用基本名称并将其应用于PATH。并在其他地方找到一个同名的文件。

此外，如果我使用LOAD_LIBRARY_AS_DATAFILE，它会阻止我找到它实际找到它的位置。

这个功能真正在这方面做了什么，它是否因操作系统版本而异？

（顺便说一下，我知道LOAD_LIBRARY_SEARCH_SYSTEM32，但是在所有操作系统版本中都不存在。我希望早在XP上运行。）

它特别令人困惑，因为我认为使用绝对路径是前一次有效修复我看到它通过PATH找到不正确的文件，作为LOAD_LIBRARY_SEARCH_SYSTEM32的便携式替代品。所以它可能会因操作系统或其他一些魔法而改变行为。

Answer 1

我观察到使用Process Monitor，用作LoadLibraryEx参数的完全限定文件名确实会导致仅检查该路径（即，它确实需要加载一个文件，因为已经加载了该名称的DLL没有。这是在32位进程中观察到的。

对于System32目录，作为C：\ Windows \ System32的参数给出的内容在64位操作系统中作为C：\ Windows \ SysWOW64出现在ProcMon中。

在

中观察到了这一点

有一点需要注意，即使使用绝对路径从指定目录加载命名DLL，其依赖DLL也会加载PATH的正常搜索。 <{1}}使用时，这不是问题。

Answer 2

如果已经加载了该名称的DLL，Windows将忽略该路径。

因此，如果某个其他路径中已经加载了foobar.dll，那么，即使您指定了另一个foobar.dll的完整绝对路径，它也只会返回一个句柄。第一个，并提出引用计数。

如果已在内存中加载了具有相同模块名称的DLL，则系统会在解析加载的DLL之前检查重定向和清单，无论它在哪个目录中。系统不会搜索DLL。