LoadLibrary() 错误代码 127答案

【问题标题】：LoadLibrary() error code 127LoadLibrary() 错误代码 127
【发布时间】：2010-11-06 09:27:06
【问题描述】：

我在使用 LoadLibrary() 时遇到问题，并收到一个对我来说没有意义的错误：

   ::SetLastError(0);

   m_hDll = ::LoadLibrary(szName);

   if (m_hDll == NULL) // Failure to load the DLL.
   {
      DWORD err = GetLastError();
   }

错误是 127（“找不到指定的过程。”）这对我调用 LoadLibrary() 没有任何意义。我没有调用 GetProcaddress( ）然而。

DLL（和应用程序）都是用 VS++ 2005 SP1 编译的。

可能出了什么问题？

【问题讨论】：

图书馆里可能没有DllMain？它应该失败::LoadLibrary吗？
如果DllMain将'last error'设置为127然后返回FALSE，在从::LoadLibrary返回之前，'last error'会被系统覆盖吗？

标签： visual-c++ loadlibrary

【解决方案1】：

让我们一步一步来：

错误消息表示找到了 dll，但缺少所需的功能。（抖动是正确的。）这意味着您拥有所需的 dll，但不是正确的版本。（Davefiddes 是对的，尽管问题可能出在任何 dll 上，而不仅仅是 Microsoft 运行时库。而且，至少对于重大更新，Microsoft 为其运行时库赋予了不同的名称，因此在这种情况下它不会成为问题。）
这没有意义，因为没有从正在加载的 dll 请求任何函数。（亚当是对的。）
因此，预计丢失的函数不是在 LoadLibrary 命令显式加载的 dll 中，而是在同时隐式加载的依赖 dll 中，因为第一个 dll 需要它。（Zebrabox 很接近。）
从属 dll 是通过导入库或 .lib 文件“静态”链接到被显式加载的库的 dll，包含在显式加载的 dll 的链接器步骤中。（我打赌你不知道“动态链接库”可以是“静态链接的”。好吧，现在你知道了。）
如果您在不同文件夹中有同一个 dll 的多个版本，那么这也可能是搜索路径问题（正如 zebrabox 所暗示的）。 Dll 路径搜索顺序本身就是一个复杂的主题：请参阅http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx。这取决于操作系统等。在可行的情况下，最安全的选择是将所有潜在的问题 dll 与您的 exe 放在同一个文件夹中。
依赖 dll 也可以有自己的依赖 dll，这会使这个问题很难解决。 Depends 可能会有所帮助，但如果没有，请尝试 filemon。在错误消息之前成功读取的最后一个 dll 是错误版本。

【讨论】：

【解决方案2】：

Microsoft gflags 工具将始终准确地告诉您哪些依赖项无法加载以及原因。

运行gflags -i your_application.exe +sls。之后在调试器下执行应用程序以捕获loader traces。

gflags 是Debugging Tools 的一部分——您可以签入C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 以查看您是否已经拥有它。您可以将该目录添加到您的路径中，或者只在 cmd.exe 中从该目录执行 gflags。

例如，在运行 gflags 之后，在 ::LoadLibrary(_T("foo")) 调用上放置一个断点并在 Visual Studio 输出窗口中查找加载程序错误时跳过它，例如

4b00:396c @ 479194074 - LdrpSnapThunk - ERROR: Procedure "?SetObject@vis_DollarMap@@QEAAXHPEAX@Z" could not be located in DLL "bar.dll"
First-chance exception at 0x0000000077307EF8 (ntdll.dll) in your_application.exe: 0xC0000139: Entry Point Not Found.
4b00:396c @ 479194074 - LdrpGenericExceptionFilter - ERROR: Function LdrpSnapIAT raised exception 0xc0000139
    Exception record: .exr 0000000000129070
    Context record: .cxr 0000000000128B80
4b00:396c @ 479194074 - LdrpHandleOneOldFormatImportDescriptor - ERROR: Snapping the imports from DLL "C:\test\64Debug\foo.DLL" to DLL "C:\test\64Debug\bar.dll" failed with status 0xc0000139

这意味着在foo.dll的加载过程中，依赖bar.dll被导入，bar.dll导入失败。

依赖项导入失败，因为过程 ?SetObject@vis_DollarMap@@QEAAXHPEAX@Z 丢失 -- 您可以将 demangle 那个过程 public: void __cdecl vis_DollarMap::SetObject(int,void * __ptr64) __ptr64。

您可能拥有错误版本的依赖项——也许您需要重新构建依赖项以使其更新。

之后运行gflags -i your_application.exe -sls 以禁用加载程序跟踪。

【讨论】：

【解决方案3】：

错误消息意味着找到了适当的 DLL，但缺少所需的过程导出。你有正确的 DLL 版本吗？

您可以使用dumpbin.exe 检查您的 DLL 导出的函数并检查拼写。

【讨论】：

我还没有调用 GetProcAddress()。可能缺少什么出口？

【解决方案4】：

安装调试工具并运行gflags -i your_application.exe +sls。然后在调试器下执行应用程序以捕获加载程序跟踪。

【讨论】：

【解决方案5】：

您的应用程序和 DLL 使用的运行时是否不匹配？

过去 VS 2005 困扰我的一个问题是，一部分是作为发布版本构建的，而另一部分是作为调试版本构建的。它们会引入不同版本的 Microsoft 运行时 DLL，这些 DLL 不兼容，因为您只能在给定进程中加载一个。

我认为您看到错误 127 的原因是因为您的 DLL 正在加载的运行时 DLL 中寻找一个函数，该函数不存在，因为它是错误的运行时。

【讨论】：

【解决方案6】：

我的两个猜测
1. LoadLibrary 调用指定DLL 的DllMain（第一次尝试并附加到您的进程）。远射，但它在那里吗？
2. LoadLibrary 将加载指定的 DLL 及其所有依赖项。所以如果DLL的依赖模块在搜索路径中找不到会导致加载失败-可以使用depends.exe检查-可用here

【讨论】：

你能澄清一下吗？ DLL 依赖项的“搜索路径”是否包括正在加载的 DLL 目录？还是只是应用程序的目录？（或者两者都没有，还是两者都有？）

【解决方案7】：

调用 LoadLibrary() 后，我得到了相同的错误代码。最后通过dependency walker发现模块（szName）的一些依赖丢失了。

【讨论】：

【解决方案8】：

我建议使用Dependency Walker 找出缺少的方法或需要或缺少的 DLL。

【讨论】：

【解决方案9】：

好的，这是我的解决方案：我们有一个复杂的依赖系统，其中有两个具有同名（即server.dll）的 DLL，但位于不同的路径上。

当client.dll 与LOAD_WITH_ALTERED_SEARCH_PATH 一起加载时，Windows 似乎无法确定应在符号解析中使用server.dll 中的哪一个（当然，server.dll 都已成功加载） .

解决方案非常简单：让加载的 dll 具有唯一的名称，即 server-1.dll 和 server-2.dll。

【讨论】：