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

Question

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.

Answer 1

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.

Answer 2

Are you missing a DllMain?

Answer 3

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)?

Answer 4

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.