Calling 32 bit unmanaged dlls from C# randomly failing

Question

Hi,

I'm having an issue when calling 32 bit delphi dll's from c# web site. The code generally runs fine, but occasionally I get an error Unable to load DLL '': The specified module could not be found. (Exception from HRESULT: 0x8007007E). This issue persists until I recycle the app pool for the site, and then it works fine again.

On the same server, there is also a web service that is calling the same set of dlls. This web service doesn't seem to have the same issue that the web site has.

Both applications are using .net framework 3.5, separate app pools on IIS.

Here is the code I'm using to wrap the dlls:

public sealed  class Mapper
{
    static Mapper instance = null;

    [DllImport("kernel32.dll")]
    private static extern bool SetDllDirectory(string lpPathName);


    private Mapper()
     {
         SetDllDirectory(ConfigManager.Path);
     }

    public static Mapper Instance
    {
        get
        {
            if (instance == null)
            {
                instance = new Mapper();
            }

            return instance;
        }
    }

    public int Foo(string bar, ref double val)
    {
        return Loader.Foo(bar, ref val);
    }
}


public static class Loader
{
    [DllImport("some.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Unicode, EntryPoint = "foo")]
    public static extern int Foo(string bar, ref double val);

}

Then I call it like this:

double val = 0.0; Mapper.Instance.Foo("bar", ref val);

Any ideas as to why it would "randomly" Unable to load DLL '': The specified module could not be found. (Exception from HRESULT: 0x8007007E).

The other problem is that I haven't been able to replicate the issue in the development environment. I thought that due to 2 applications calling the same dlls, that there could be some locks occurring. To replicate this, I created an app that spawned multiple threads and repeatedly called the 32bit dlls, and then used the web site to call these same dlls. I still couldn't replicate the issue.

Some possible fixes that I can think of:

1. Wrap the 32 bit dlls in web service (because the webservice doesn't seem to suffer from the same problem). But this may be worthless if it turns out that the web service also fails.
2. Set up state server for the session state and periodically recycle the app pool for the site.This isn't fixing the problem, only avoiding it.
3. Wrap the dll's in exe, and call that exe. Then I shouldn't get the same issue. But this also seems like a hacky solution.
4. Implement the mapper class differently ? But how else should I be doing the call? The other draw back is that other applications are using this mapper, so I'd need to change there code too.

Any suggestions?

Thanks

Answer 1

I don't know what realy cause this problem, but in my experiance this error message can be caused by following reasons:

• the dll that you are using needed a runtime library which is not available at the time of loading it (like viusal c++ runtime library). you need the exact version of the library. ofr example if your dll is writen with runtime 2008 sp1 you need exactly the same version.

• one of the dependencies of the dll is not available. you can check this by using the dependency walker from here

• also you have to be sure that your dll and the calling application all must be 32-bit or 64-bit. some time i get the same error when i want to call a 32-bit dll from a 64-bit application

I know this is not truly your answer but i hope it would help you find the solutin.

Answer 2

To fix this issue (its stopped happening now), I left the mapper code as is, but in the calling application I manually set the path (even though the mapper dll does it most of the time).

So in the main app I make a call to append the path of the directory where the dll's are located.

private static void AddEnvironmentPaths(string[] paths)
    {
        string path = Environment.GetEnvironmentVariable("PATH") ?? string.Empty;
        path += ";" + string.Join(";", paths);

        Environment.SetEnvironmentVariable("PATH", path);
    }

What's strange is that the mapper class works most of the time, but sometimes stopped. Adding the path with the above code seems to have solved the issue.