Which DLL is loading [DllImport]?

Question

I use the [DllImport] attribute to import the native DLL into my application, but the DLL that it loads is not in the local bin folder. It loads from another place on the system, but I cannot decide where.

It works on my dev machine, but not on a clean one.

I turned on Fusion logging, and this shows only managed assemblies.

I reset this process using Sysinternals Process Explorer and told me about it in C:\Windows\System32 , but I can’t see the file there in Windows Explorer.

It may be worth noting that I am running 64-bit Windows 7, but the DLL only supports x86, so I had to force my application to be x86. Is there some kind of redirect that changes where x86 files are downloaded?

DllImport is a custom Silicon Labs USB driver. [DllImport ("SiUSBXp.dll")]

I also used the command line to make dir si* in the System32 folder, and the file does not exist there.

Answer 1

File File Redirector will start:

The% windir% \ System32 directory is reserved for 64-bit applications. Most DLL file names were not changed when creating 64-bit versions of DLLs, so 32-bit versions of DLLs are stored in a different directory. WOW64 hides this difference using a file system redirector.

In most cases, when a 32-bit application tries to access% windir% \ System32, access is redirected to% windir% \ SysWOW64.

So, although the process believes that it loaded the DLL from System32 , it is probably loaded from SysWOW64 And yes, the numbers are wrong from what you expect.

Answer 2

You want to read this: the LoadLibrary function , and in addition, you also want to read this Search Order for a dynamic link library .

Note. They belong to the native Win32 API, but this is the one used by the [DllImport] attribute.

The file may not be displayed in Explorer because you need to enable Show All Files - many common [DllImport] directives (for example, kernel32 ) are intended for Win32 DLLs, which are classified as operating system files and therefore are hidden by default.

Answer 3

DLLImport searches the following paths:

• Downloaded DLL files (if they are already loaded, there is no need to search for a file)
• Executable directory for the current process
• Current directory.
• "System" directory. (i.e. c: \ Windows \ System32)
• The Windows directory. (i.e. c: \ Windows)
• Directories listed in the PATH environment variable.

Answer 4

The actual source code for DllImport is here:

https://github.com/gbarnett/shared-source-cli-2.0/blob/master/clr/src/vm/dllimport.cpp

As you can see, he first tries to find an unmanaged library in the internal .Net cache.

If this fails, but the absolute path is specified, it loads the library with that path.

If the absolute path is not specified, it looks in the following places:

1) A folder containing the assembly manifest file containing DllImport.

2) The folder specified in Assembly.CodeBase.

3) All places where LoadLibraryExW looks.

If all this fails, he tries to interpret it as "file name, assembly name."

He then adds the library to his internal cache.