Delay Load DLL: "Exception 0xC06D007E: Module not found" when application started multiple times

Question

I have a case of an intermittent crash in my application where we use Delay Load DLL. There are a few different call-stacks where we have seen the crash, but it always crashes when raising 0xC06D007E: Module not found in __delayLoadHelper2.

The exception is raised when calling the process multiple times in a row (in series). Here is a sample call stack:

KERNELBASE.dll!RaiseException()  + 0x3d bytes   
MYDLL.dll!__delayLoadHelper2(const ImgDelayDescr * pidd=0x000000000012f650, __int64 (void)* * ppfnIATEntry=0x000000000012f570)  Line 331    C++
MYDLL.dll!__tailMerge_MyDelayLoadDLL_dll()  + 0x3f bytes    Unknown
MYDLL.dll!MyUserFunction()  Line 91 + 0x5 bytes C++

The c++ application is using Delay Load DLL to load .NET code.

The computer on which the crash occurs is very powerful machine (12 cores CPU, 48 gig ram), I am not sure if it has an influence on it. But since the crash does not happen all the time, it looks like a race condition, or resource issue.

This forum thread describes my case, but there is no solution.

Any idea why this could be happening?

Answer 1

I have this same crash on my application, and the callstack is exactly the same too. However my crash is different in that a native DLL has a delay load dependency on another native DLL.

I would never ever delay load a .NET assembly. .NET assemblies are supposed to be loaded using the managed assembly loader functions. They should also not be loaded by calling LoadLibrary on them either.

In the end, I'm not sure what is causing the crash, but I would remove delay loading altogether for a .NET assembly.

Answer 2

I had this problem when I tried to run a debug version of my program on another machine that did NOT have the debug version of the Visual Studio C++ runtimes on that machine. (The debug dlls are often named a little bit differently having an extra "D" somewhere in the assembly name)

The release configuration of my program worked fine because I had the redistributable VS C++ runtimes on it.

For completeness, I'll put the obvious answer to this question, but I sincerely don't mean for it to seem condescending... The module loader could not find a module that it was dependent on! The more I troubleshoot stuff like this, I tell myself more and more to "believe the error message"

Dependency Walker (depends.exe) should be your friend in this case, although I can't say with confidence how it deals with delay loaded modules.