DllNotFoundException with HRESULT 0x8007007E when loading 64-bit dll

Question

I downloaded zlib and compiled the library as both Windows 32-bit and Windows 64-bit dll. I now have zlibwapi.dll and zlibwapi64.dll.

The dlls are copied into my application folder and are referenced as follows:

[DllImport(@"zlibwapi.dll",   EntryPoint = "uncompress", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = false)]
private static extern int uncompress32(
    IntPtr dest,
    ref uint destLen,
    [In(), MarshalAs(UnmanagedType.LPArray)] byte[] source,
    uint sourceLen
);

[DllImport(@"zlibwapi64.dll", EntryPoint = "uncompress", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = false)]
private static extern int uncompress64(
    IntPtr dest,
    ref uint destLen,
    [In(), MarshalAs(UnmanagedType.LPArray)] byte[] source,
    uint sourceLen
);

At runtime I check whether I'm 32-bit or 64-bit, and call appropriate version.

This works fine if I'm 32-bit, but the 64-bit version gives

Cannot load DLL "zlibwapi64.dll": Module not found. (HRESULT exception: 0x8007007E)

I've found many similar questions on the Internet, and the suggested reason was that the library depends on some other libraries, and it is those libraries that may not be found.
This does not seem to the case:

• zlibwapi64.dll only depends on Kernel32.dll and MSVCR90.dll. I do have VS2008 C++ runtimes installed, both 32 and 64 bit.
• When I try to load zlibwapi64.dll from a non-managed C++ application, it loads no problem. It is C# that fails to load it.

I have tried setting absolute path to the 64-bit dll, it does not help.

How do I make it work?

Answer 1

It is a fairly basic "file not found" kind of error, unfortunately it doesn't tell you explicitly what DLL it couldn't find. You already know about the issue with dependent DLLs. Note that you can avoid the irksome dependency on msvcr90.dll by compiling the code with /MT

You'll need to debug the problem and that requires getting insight in where it is looking for DLLs. One good tool is SysInternals' ProcMon utility, it shows you exactly where your program is looking for files. You should see it probing for the DLL, searching through the directories of the PATH and failing to find the file.

Unfortunately ProcMon is a bit chatty and has a habit of drowning you in the data. A more dedicated tool is GFlags.exe, a tool available from the Debugging Tools for Windows package. These days included with the Windows SDK. Stored in c:\program files (x86)\debugging tools for windows\gflags.exe after you installed it. You can turn on the "Show loader snaps" option. On later Windows versions, that tells the Windows loader to generate debugging messages when it is searching for DLLs. They'll appear in the Output window when you enable unmanaged debugging.

Try ProcMon first, much easier to get going.

And of course consider pure managed solutions so you are not fighting these kind of install problems. Good ones are DotNetZip and SharpZipLib, take their first google hit.