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?

Auto

Are you using both in the same application? Keep in mind 32 bit application can only use 32 bit dlls and 64 bit application can only use 64 bit dlls. – Necker

@Dani I'm using either, depending on a runtime check. The framework does not attempt to load a dll until it is referenced. When I set the project to x86, it runs ok and calls uncompress32 without an attempt to call uncompress64. When I set the project to x64, it does not attempt to call uncompress32 and fails to call uncompress64 – Auto

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.

Outskirts

Procmon shows that zlibwapi64.dll is found, and then MSVCR90.dll is not. It's getting searched in the default order and doesn't get found. Which is sort of expected, because that dll is located in Windows\winsxs\<multiple locations>. The question then is, why unmanaged C++ manages to load it with LoadLibrary? And is it correct for the VC++ runtimes to install themselves in this way? – Auto

Surely it works because your unmanaged C++ exe has already loaded msvcr90.dll. Your DLL is probably missing the required manifest. Not sure what happened in your DLL project, this is normally done automatically, but do seriously consider using /MT to completely avoid the problem. – Outskirts

Surely it works because your unmanaged C++ exe has already loaded msvcr90.dll -> facepalm.jpg – Auto

Manifest generation was disabled in the downloaded project. Not sure why. Enabling it made it work. – Auto

Decided to give Procmon a try. It uncovered the specific dll loading problem. Very thankful to find this detailed informative answer. – Size

@DylanCrocker Project properties - Confiuration properties - Linker - Manifest file. – Auto

"Note that you can avoid the irksome dependency on msvcr90.dll by compiling the code with /MT" +1 this fixed my problem. Project properties > C/C++ > Code Generation > Runtime Library: /MT – Awash

Answer 2

Another good tool for examining Dll dependencies is Dependency walker (depends). It looks at the file in a static way so a little easier than using process monitor.

http://www.dependencywalker.com/

Protonema

I've already done static analysis, which is how I knew about Kernel32.dll and MSVCR90.dll. – Auto

Dependency walker can also be used as DYNAMIC dependency analysis tool when running in Profiling mode. This feature is excellent. – Bezel