Unable to load DLL (Module could not be found HRESULT: 0x8007007E)

414,991

Solution 1

From what I remember on Windows the search order for a dll is:

  1. Current Directory
  2. System folder, C:\windows\system32 or c:\windows\SysWOW64 (for 32-bit process on 64-bit box).
  3. Reading from the Path environment variable

In addition I'd check the dependencies of the DLL, the dependency walker provided with Visual Studio can help you out here, it can also be downloaded for free: http://www.dependencywalker.com

Solution 2

You can use the dumpbin tool to find out the required DLL dependencies:

dumpbin /DEPENDENTS my.dll

This will tell you which DLLs your DLL needs to load. Particularly look out for MSVCR*.dll. I have seen your error code occur when the correct Visual C++ Redistributable is not installed.

You can get the "Visual C++ Redistributable Packages for Visual Studio 2013" from the Microsoft website. It installs c:\windows\system32\MSVCR120.dll

In the file name, 120 = 12.0 = Visual Studio 2013.

Be careful that you have the right Visual Studio version (10.0 = VS 10, 11 = VS 2012, 12.0 = VS 2013...) right architecture (x64 or x86) for your DLL's target platform, and also you need to be careful around debug builds. The debug build of a DLL depends on MSVCR120d.dll which is a debug version of the library, which is installed with Visual Studio but not by the Redistributable Package.

Solution 3

The DLL has to be in the bin folder.

In Visual Studio, I add the dll to my project NOT in References, but "Add existing file". Then set the "Copy to Output Directory" Property for the dll to "Copy if newer".

Solution 4

This is a 'kludge' but you could at least use it to sanity-test: Try hard-coding the path to the DLL in your code

[DllImport(@"C:\\mycompany\\MyDLL.dll")]

Having said that; in my case running dumpbin /DEPENDENTS as suggested by @anthony-hayward, and copying over 32-bit versions of the DLLs listed there into my working directory solved this problem for me.

The message is just a bit misleading, becuase it isn't "my" dll that can't be loaded - it's the dependencies

Solution 5

Try to enter the full-path of the dll. If it doesn't work, try to copy the dll into the system32 folder.

Share:
414,991
Ingimar Andresson
Author by

Ingimar Andresson

Updated on August 14, 2021

Comments

  • Ingimar Andresson
    Ingimar Andresson almost 3 years

    I have a dll library with unmanaged C++ API code I need to use in my .NET 4.0 application. But every method I try to load my dll I get an error:

    Unable to load DLL 'MyOwn.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

    I have read and tried several solutions I have found on the internet. Nothing works..

    I have tried using following methods:

    [DllImport("MyOwn.dll",  CallingConvention = CallingConvention.Cdecl)]
    [return: MarshalAs((UnmanagedType.I4))]
    public static extern Int32 MyProIni(string DBname, string DBuser_pass,
        string WorkDirectory, ref StringBuilder ErrorMessage);
    

    When I tried following this article and when I run this example (from the downloaded code) it runs without a problem (the dll used is in the bin/debug folder)

    I have copied my dll (along with all the files the it depends on into my bin folder).

    I also tried this approach but got the same error:

    [DllImportAttribute(MyOwnLibDllPath, EntryPoint="TMproIni")]
    [return: MarshalAs(UnmanagedType.I4)]
    public static extern  int MyproIni(string DBname, string DBuser_pass, 
        string WorkDirectory, ref StringBuilder ErrorMessage);
    

    Any suggestions?

  • Ingimar Andresson
    Ingimar Andresson over 12 years
    found some dependency's missing (Oracle and some dll from IE). Need to install Oracle since my dll depends on that..then i will know :) Found the problem with DependencyWalker ;)
  • Ingimar Andresson
    Ingimar Andresson over 12 years
    is it ok to have all dependency's in the System32 folder and my dll somewhere else?
  • display101
    display101 over 12 years
    No worries, it's saved many hours of head scratching for me, great little tool! :-)
  • DiligentKarma
    DiligentKarma about 11 years
    +1 to Keith Halligan for suggesting DependencyWalker. It told me that the not all the dependencies had the same CPU type (x86/x64). I copied all the files that had the same CPU type to my application's bin folder, and that resolved the problem.
  • Igor Mironenko
    Igor Mironenko almost 11 years
    Every dll I can find on my system has DependencyWalker claiming that there's an error with different CPU types - even System.Web.Mvc.dll. There's some sort of false alarm here.
  • RenniePet
    RenniePet about 10 years
    In my case the problem was attempting to load a C++ DLL compiled for Debug. That needs the C++ debug runtime, which means you have to install Visual Studio. Or recompile the DLL for Release, and install the C++ runtime distributable.
  • user510101
    user510101 over 9 years
    adding the VS C++ redistributables was it for me! needed v10.0 (2010). Thanks mucho!!!
  • BVB
    BVB over 9 years
    Is there any way to tell whether 64-bit or 32-bit versions of the redistributables are required?
  • Anthony Hayward
    Anthony Hayward about 9 years
    dumpbin /ALL will tell you whether my.dll is x86 of x64
  • ljk321
    ljk321 over 7 years
    For those who still suffers from this problem, if you use debug binary, the C++ runtime redistributables version needs to be exactly the same as where you built it.
  • Sean Duggan
    Sean Duggan over 6 years
    This fixed things for me too. Feels kind of weird to put the DLLs in the main project instead of the project that's actually using them, though...
  • spy
    spy about 5 years
    @skyline75489's comment saved the day for me. C++ library worked just fine on my machine but failed to load everywhere else due to VS linking it to the debug version of msvcr.
  • Admin
    Admin almost 5 years
    Dependencies will also be searched as per windows dll search path order as specified by stackoverflow.com/a/9003290/4434329
  • m4l490n
    m4l490n almost 4 years
    @SeanDuggan that is because it is a "dynamic linking library" meaning that it is used (loaded) at run time as opposed to static libraries that are used at linking time.
  • m4l490n
    m4l490n almost 4 years
    I have tried adding the dll into the bin\Debug and the obj\Debug directories and I keep getting the "Unable to load DLL"