64 bit managed assembly with unmanaged dependencies not loading in IIS / ASP.NET MVC 4

Question

I have an almost empty ASP.NET MVC4 project referencing a 64 bit managed assembly, which has a set of unmanaged dependencies.

The managed assembly is referenced the normal way through references.

The unmanaged dependencies are copied to the bin folder on a post build event - and are present when the web app is started (this has been verified).

The problem is that I get:

Could not load file or assembly 'msvcm80.DLL' or one of its dependencies. A dynamic link library (DLL) initialisation routine failed. (Exception from HRESULT: 0x8007045A)

This is one of the unmanaged dependencies. The full list is:

• iconv.dll
• lbm.dll
• libeay32.dll
• msvcm80.dll
• msvcp80.dll
• msvcr80.dll

The managed dll is built against x64 and all the dependencies are also x64 (verified by using Dependency Walker).

Now I have also created a blank console app, a windows form app and a self-hosted Web Api which contains the the same code (for firing up instances using the managed assembly) and they all work fine (when forcing the build target to be x64).

Using Fusion Log (clearing it first, then loading the web app and refreshing the log viewer), I can see that there are problems loading:

• iconv.dll
• libeay32.dll
• lbm.dll

All of them have similar log files:

LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/3b2d5b3e/b1b5f1f5/iconv.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/3b2d5b3e/b1b5f1f5/iconv/iconv.DLL.
LOG: Attempting download of new URL file:///C:/.../bin/iconv.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\...\bin\iconv.dll
LOG: Entering download cache setup phase.
ERR: Error extracting manifest import from file (hr = 0x80131018).
ERR: Setup failed with hr = 0x80131018.
ERR: Failed to complete setup of assembly (hr = 0x80131018). Probing terminated.

So it actually figures out that the dependencies are in the local bin folder, but it cannot use them for some reason.

What does the error "Error extracting manifest import from file (hr = 0x80131018)." mean?

The dependencies are not in GAC and they are not registered using regsvr32 (not COM).

What puzzles me is that is works fine outside IIS (I even tried to set up the credentials on the app pool to be the same as the local network credentials - which did not make a difference, of course).

Any good ideas of how to debug this issue?

EDIT: I am now able to run the ASP.NET site on my local developer machine, but not when it is deployed onto another server.

The "fix" for my local machine, was to remove the msvcm80.dll (C runtime) from the bin directory. The assembly is (probably) still needed, but is looked up somewhere else (presumably because I have the "correct" version of CRT (distributable) installed in WinSxS).

Digging into that, I see that the managed assembly is supposedly dependent on msvcm80.dll version 8.00.50727.6195 (x64), but that particular version is not installed on my local system (I only have it in a dependency folder) - but I do have a newer one in WinSxs (8.00.50727.6910).

So which one is IIS picking up when not adding it directly in the bin folder?

2nd EDIT: So it looks like lbm.dll has a direct dependency to msvcr80.dll, but it also has a dependency to iconv.dll which again has a dependency to msvcr80.dll. However, according to Dependency Walker (depends.exe), those two dependencies are not resolved from the same directory (even when they have the same version!).

If I make sure that the indirect dependency is in the PATH environment variable and the 2nd dependency is in WinSxS it works. This is obviously not good enough, but I cannot figure out how to enforce that the direct and indirect dependency is loaded from a single location/file.

Answer 1

Using a tool like Dependency Walker you will find that lbm.dll and its dependencies only depend on msvcr80.dll and not msvcp80.dll and msvcm80.dll even though these two files are included in the Microsoft.VC80.CRT.manifest used by lbm.dll to load the correct version of the Visual C++ 2005 runtime library.

Removing msvcp80.dll and msvcm80.dll from you bin folder should fix your problem.