Question

This program’s stdafx.h is a little like this below.

// ...
#import "./lib/64/msado15.dll" rename("EOF", "EndOfFile") no_namespace
// ...

The program works okay and there are no problems.

I was curious about what would happen if I deleted msado15.dll.
So, I deleted it, and the program still works fine.

I assumed that why the program works without msado15.dll in the same directory must be the dll file is loaded somewhere else.

To make sure exactly where the dll is loaded, I used “Dependancy Walker”, and I found out this program is not loading msado15.dll at all.

I would be glad if I could figure out what I’m missing.

Thanks in advance.

Answer 1

Dependency Walker can only see static DLL dependencies (where there’s a reference in the EXE’s imports table). If a DLL is loaded at runtime via LoadLibrary (or by delay loading — using /delayload), Dependency Walker will not be able to see this.

#import doesn’t actually impose a static dependency on the DLL. It loads the COM typelibrary information from the DLL at compile time. This is transformed into C++ bindings for the COM classes and interfaces defined in the typelibrary. You can see these as .tli and .tlh files in your Debug or Release directory. You might be able to remove the DLL file, and — as long as these files still exist — VS might continue to build your project successfully.

Similarly, at runtime, since #import doesn’t actually impose a static dependency on the DLL (that is: it won’t add it to the imports table in the EXE), Dependency Walker will be unable to see this dependency.

At runtime, however, the EXE will call (indirectly) LoadLibrary, and (if the DLL is missing) this will cause a failure at runtime, which your program might deal with appropriately, or which might cause your program to crash.

Even with all that said, #import merely imports a COM typelibrary. The COM typelibrary defines the interfaces used in the COM objects, along with the CLSID values of those objects. In order to find the code that implements the COM objects, the CLSID values are resolved using the registry (in HKEY_CLASSES_ROOT\CLSID. The code implementing the COM objects may not actually be in the same binary as the original typelibrary.

This means that the DLL may not even be required at runtime. I think that this is rare, however.

Moreover, the COM objects may be implemented as out-of-process objects (meaning that another EXE is loaded). In this case, all that’s loaded into your process will be the proxy/stub DLL configured for the relevant interfaces. Often, these will be defined using the TLB (in which case, your #import-ed DLL will be loaded); but they may be implemented in a completely different DLL. Either way, the DLL will be loaded dynamically, which means that Dependency Walker won’t see it.

To see which DLLs are loaded by the process, you will need something like SysInternals Process Monitor or Process Explorer.