In some PCs I get: Unable to load the DLL, exception from HRESULT: 0x8007007E RRS feed

  • Question

  • Hi all,

    the story is not stable. situationis confusing.
    Everything works fine in developper's computers (Win2K+VS2005), but doesn't work in orher's (System Enginerr's) computers (Win2K). Some of them have development environment, and some don't.

    * I have an unmanaged DLL (written in CPP),
    * I wrote a dotNET (managed) application (Csharp) that calls the DLL above.
    In some computers (including mine) it works fine. In the others, the application can't access the DLL.

    In the managed Csharp application I declared the interface as follow:
    [DllImport("myCppDll")] public static extern int InitCppDll(int a, int b);

    and then I call the entry in the DLL:

       // first of all: be sure that the DLL is there:
       if (File.Exists("myCppDll.dll")
       { print that the file exists, doesn't matter how to print}

       ret - InitCppDll(i,j); // this is the main line
    catch (System.DllNotFoundException e)
       print the exceptiondetails
    and there are additional catches, but they are not relevant.

    All this doesn't work on all the PCs, but on a part of them.

    I found a suggestion of using a tool calls FileMon.exe that shows access of the application to any
    other files.
    When I used it I found, in the PCs that do not find the DLL, that the Windows OperatingSystem is trying to find out the DLL, but in folders that do not exist at all.
    Example: if the DLL exists in a folder located somewhere in the local network calls: "kuku", the PC combines a path name of something like "c:\WINNT\system32\kuku\...\myCppDll.dll"
    Of course, there is no such folder, and so, the DLL cannot be found there.
    There is a list of about 10 such retries, all of them relate to non-exist folders.

    How cal I guide the system about the exact location of the DLL ?

    I thought about loading the DLL using LoadLibrary() function, similar to the CPP case, but the function works differently, no parameter that diverts to the DLL in dotNET+Csharp.


    Monday, December 15, 2008 4:36 PM

All replies