5

我有一个 dll “mytest.dll”，当通过 加载时LoadLibrary()，返回 NULL（和 127 作为GetLastError()）。如果我在“mytest.dll”上使用 DependencyWalker，它会报告它应该正确加载并且正确找到所有 DLL。在主机 exe 上运行 DependencyWalker 的探查器选项会在日志中为我提供以下相关部分：

00:00:55.099：由线程 0xBBC 在地址 0x07860000 加载“mytest.DLL”。成功挂接模块。
00:00:55.115：线程 0xBBC 在地址 0x76E24285 的“NTDLL.DLL”中发生第一次机会异常 0xC0000139（未找到 DLL）。
00:00:55.115：线程 0xBBC 在地址 0x07860000 处卸载了“mytest.DLL”。
00:00:55.115：LoadLibraryW("mytest.dll") 由线程 0xBBC 返回 NULL。错误：找不到指定的过程 (127)。

有没有办法调试它以找出 NTDLL.DLL 报告的 DLL Not Found 消息试图寻找什么？还是我应该在别处寻找问题的根源？

请注意，从另一个应用程序加载相同的“mytest.DLL”似乎可以正常工作。

4

3 回答 3

3

使用SysInternals 中的Process Monitor或FileMon可能会为您提供有关 myTest.dll 是否根本不在寻找它的位置的线索。

于 2009-04-27T21:42:44.210 回答
3

您的应用程序是否会在未找到的初始加载（可能）之后尝试通过 GetProcAddress 调用特定的 DLL 函数？它是 32 位还是 64 位应用程序？

如果它按照您的建议在另一个应用程序中正确加载，那么它可能有一个正确的入口点。

快速的谷歌搜索表明，您返回的错误代码可能来自 DLL 中缺少的函数名称（或特定函数的序数值）。我建议在Exescope之类的东西中打开 DLL并检查导出列表。

它还可以解释为什么 DLL 与另一个应用程序一起工作（也许另一个应用程序在 DLL 中使用不同的导出函数）？

于 2009-04-27T21:51:31.977 回答
2

DependencyWalker 显示隐式依赖项（Windows 加载程序自动处理的依赖项）。您使用 LoadLibrary 加载的 DLL 是显式依赖项，而 DependencyWalker 无法找到它们（例如，库名称可能是从 ini 文件中读取的，而 DependencyWalker 无法推断出这一点）。

DLL 在一个应用程序中工作而不在另一个应用程序中工作一点也不稀奇。在最常见的情况下，一个应用程序已经加载了所需的 dll，而另一个没有。如果 dll 不在路径上，则您的 dll 将在第一种情况下工作，而不是在第二种情况下工作。

无论如何，请按照 Michael Burr 的建议使用 FileMon。尽管 SysInternals 网站说 FileMon 已经过时，但它仍然比 ProcMon 更容易使用。

于 2009-04-27T23:13:15.727 回答