DllNotFoundException with HRESULT 0x8007007E when loading a 64-bit dll

Question

I downloaded zlib and compiled a library of both 32-bit Windows and 64-bit Windows dll. Now I have zlibwapi.dll and zlibwapi64.dll .

The DLL files are copied to my application folder and are listed 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 if I am 32-bit or 64-bit, and call the appropriate version.

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

Unable to load DLL "zlibwapi64.dll": module not found. (HRESULT exception: 0x8007007E)

I found a lot of similar questions on the Internet, and the alleged reason was that the library depends on some other libraries, and these libraries cannot be found.
This is not like the case:

• zlibwapi64.dll depends only on Kernel32.dll and MSVCR90.dll. I have a VS2008 C ++ runtime, both 32 and 64 bit.
• When I try to download zlibwapi64.dll from an unmanaged C ++ application, it does not load any problems. This is C # that does not load it.

I tried to set the absolute path to the 64-bit dll, this will not help.

How can I make it work?

Answer 1

This is a fairly simple “file not found”, but unfortunately, it does not explicitly tell you which DLL it could not find. You already know about the problem with dependent DLLs. Please note that you can avoid over reliance on msvcr90.dll by compiling code with / MT

You will need to debug the problem, and you need to get an idea of ​​where it is looking for DLLs. One of the good tools is the ProcMon SysInternals utility , it shows where exactly your program is looking for files. You should see how it examines the DLL by looking at the PATH directories and not finding the file.

Unfortunately, ProcMon is a bit chatty and has a habit of drowning you in data. A more specialized tool is GFlags.exe, a tool available from the Debugging for Windows package. These days are included in the Windows SDK. It is stored in c: \ program files (x86) \ debugging tools for windows \ gflags.exe after installing it. You can enable the "Show bootloaders" option. In later versions of Windows, this tells the Windows loader to generate debug messages when looking for the DLL. They will appear in the Output window when you enable unmanaged debugging.

Try ProcMon first, it’s much easier to get started.

And, of course, consider clean, manageable solutions so as not to deal with such installation problems. Good ones are DotNetZip and SharpZipLib, make your first Google hit.

Answer 2

Another good tool for exploring Dll dependencies is dependency hangs (depends). It looks at the file in a static way, so it’s a bit easier than using the process monitor.

http://www.dependencywalker.com/