DllImport generates System.DllNotFoundException

Question

I’m having some difficulties while trying to consume an unmanaged-code dll from my application (written in C# framework 4.0). I’m using the dll import as follows

[DllImport(@"C:\MGW_SDK.dll", EntryPoint = "fInicializaSDK")]
public static extern int fInicializaSDK();

The weird thing is that when called from my development environment (Windows XP) it works just fine, but when on the production server (Windows7) it generates the following exception:

System.DllNotFoundException: Unable to load DLL ' C:\MGW_SDK.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E) at Comtpaq.AdminPack.SDKWrapper.fInicializaSDK() at Comtpaq.AdminPack.AdminPaqRepository.InitializeSDK() in C:\Work\AgroIn\AdminPaqRepository.cs:line 30

I already ran Dependency Walker, which shows the following dependency as conflicted: C:\windows\system32\SHLWAPI.DLL

I already tried copying that dll to my deployment directory

The MGW_SDK.dll is on c:\ (as the path says)

I already installed C Runtime Library

I also noticed some interesting stuff: on the exception, the development path is showing C:\Work\AgroIn\AdminPaqRepository.cs:line 30

What else could be the problem here?

Edit

I built a small console application with just one of the extern/dllimport methods that I use from MGW_SDK.dll and ran it with no problem (no DllNotFoundException whatsoever), so this seems to be related to the application that I'm building (a WCF Service). This service is hosted on the WAS, but I'm still unable to find the issue.

Anodize

both production and developer OSes are 32bit? .NET aaplication is compiled for AnyCPU target platform? – Kazantzakis

yes, both OSs are 32 bit and they are compiled as AnyCPU, the application itself works, is just this component that is giving me pain. – Anodize

What kind of app is it? Desktop, ASP .NET? – Hazel

That is actually a WCF Service – Anodize

Have you tried to put all required DLLs in your app folder? Just to make sure it can locate them. – Hazel

Yeah all the dlls are placed on the deployment folder – Anodize

Answer 1

Well, this was a very tricky problem. It was not related to dll dependencies and not related to the dll location either. It was not about how I was calling the DllImport. It was a permissions problem.

Basically this issue is solved by taking out and then adding back the permissions for execute on the folder where the dlls are. See this article (Wayback machine).

Solution

---

Oracle 9.2 Client software requires that you give the Authenticated User privilege to the Oracle Home by following these steps:

1. Log on to Windows as a user with Administrator privileges.

2. Launch Windows Explorer from the Start Menu and and navigate to the ORACLE_HOME folder. This is typically the "Ora92" folder under the "Oracle" folder (i.e. D:\Oracle\Ora92).

3. Right-click on the ORACLE_HOME folder and choose the "Properties" option from the drop down list. A "Properties" window should appear.

4. Click on the "Security" tab of the "Properties" window.

5. Click on "Authenticated Users" item in the "Name" list (on Windows XP the "Name" list is called "Group or user names").

6. Uncheck the "Read and Execute" box in the "Permissions" list under the "Allow" column (on Windows XP the "Permissions" list is called "Permissions for Authenticated Users").

7. Re-check the "Read and Execute" box under the "Allow" column (this is the box you just unchecked).

8. Click the "Advanced" button and in the "Permission Entries" list make sure you see the "Authenticated Users" listed there with:

     Permission = Read & Execute 
     Apply To = This folder, subfolders and files 
   

   If this is NOT the case, edit that line and make sure the "Apply onto" drop-down box is set to "This folder, subfolders and files". This should already be set properly but it is important that you verify this.

9. Click the "Ok" button until you close out all of the security properties windows. The cursor may present the hour glass for a few seconds as it applies the permissions you just changed to all subfolders and files.

10. Reboot your computer to assure that these changes have taken effect (IMPORTANT).

Re-execute the application and it should now work.

Anodize

The provided link is now broken. – Concertina

Answer 2

The root of C is one of the places UAC will not let you write. Sometimes unmanifested apps that ask to read from a protected area end up reading from the virtualized equivalent - and your DLL will not be there. Try moving the DLL to a different folder (not the root of C, not anything under Program Files) and see if that solves it. If it does, you can leave it there or (better) put a manifest on your app to prevent virtualization.

Impartial

i tried another path as well (not in the root), and happend the same error – Anodize

Answer 3

Have you tried using Assembly Binding Log Viewer?

Hazel

Does that work for DllImport/PInvoke libraries? It looks like it is only for CLI assemblies. – Advowson

Can't be sure. I googled around but I didn't find any entries specifying it either works or does not for P/Invoke libraries. Worth a try, I think. – Hazel

i ran it on where i have the service, but shows no information, however when i run it on the client it shows the processes... does it need a Window in order to log? how about WCFs? – Anodize

Answer 4

Don't know if this will work for sure but have you tried registering MGW_SDK.DLL using regsrv32 or other installation package on Win7 box?

Also try to find out if the dependencies of MGW_SDK.DLL are also available on Win7 machine (either registered on system or in your application folder will work)

Sleet

i tried registering the dll using regsvr32 but it didn't work The Module "MGW_SDK.dll" failed to load Make sure the binary is stored at the specified path or debug it tp check problems with the binary or dependent .DLL files. The specified procedure could not be found the only dependency that i see here failing (dependency walker) is SHLWAPI.DLL – Anodize

most probably it is making use of XP specific version of Shell API. try right clicking and setting its compatibility mode to XP or contact owners/publishers of MGW_SDK.dll to get updated version. – Sleet