LoadLibrary fails: First chance exception 0xC0000139 (DLL Not Found) – How to debug?

LoadLibrary fails: First chance exception 0xC0000139 (DLL Not Found) – How to debug?

情痴 发布于 2021-11-29 字数 1109 浏览 760 回复 3 原文

I have a dll "mytest.dll" that when loaded via LoadLibrary(), returns NULL (and 127 as the GetLastError()). If I use DependencyWalker on "mytest.dll", it reports that it should load correctly and that all DLLs are found correctly. Running the profiler option of DependencyWalker on the host exe gives me this relevant section in the log:

00:00:55.099: Loaded "mytest.DLL" at address 0x07860000 by thread 0xBBC.  Successfully hooked module.
00:00:55.115: First chance exception 0xC0000139 (DLL Not Found) occurred in "NTDLL.DLL" at address 0x76E24285 by thread 0xBBC.
00:00:55.115: Unloaded "mytest.DLL" at address 0x07860000 by thread 0xBBC.
00:00:55.115: LoadLibraryW("mytest.dll") returned NULL by thread 0xBBC. Error: The specified procedure could not be found (127).

Is there a way to debug this to find out what the DLL Not Found message that NTDLL.DLL reports is trying to look for? Or should I be looking elsewhere for the source of the problem?

Note that loading this same "mytest.DLL" from another application seems to work correctly.

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。

扫码加入群聊

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

下壹個目標 2022-06-07 3 楼

DependencyWalker shows implicit dependencies (dependencies that are automatically handled by the Windows loader). DLLs you load with LoadLibrary are explicit dependencies and DependencyWalker has no way to find them (for example, the library names might be read from an ini file, and there's no way that DependencyWalker could infer this).

It's not at all unusual for a DLL to work in one app and not in another. In the most common scenario, one application already has a required dll loaded and the other does not. If the dll is not on the path, your dll will work in the first case and not in the second.

Anyway, go with Michael Burr's suggestion and use FileMon. Even though the SysInternals web site says that FileMon is outdated, it's still a lot easier to use than ProcMon.

往事风中埋 2022-06-07 2 楼

Using Process Monitor or FileMon from SysInternals might give you a clue as to whether myTest.dll is simply not where it's being looked for.

九公里浅绿 2022-06-07 1 楼

Could your application be trying to call a specific DLL function via GetProcAddress after the initial load (perhaps) which is not found? Is it a 32 or 64 bit application?

If it is loading correctly in another application as you suggest, then it probably has a correct entry point.

A quick google search suggests that the error code you are getting back is likely from a missing function name (or specific function's ordinal value) in the DLL. I'd suggest opening the DLL in something like Exescope and inspect the exports list.

It might also explain why the DLL works with another application (perhaps the other application uses different exported functions in the DLL)?