COM Server DLL Server Dependency Search Rules

Question

Consider the following file organization on Windows:

[app folder] app.exe [folder 'sub'] com_server.dll regular.dll helper.dll 

Also suppose the following:

• Both com_server.dll and regular.dll are statically associated with the function in helper.dll, so helper.dll loads when they are.
• app.exe has no static dependencies.
• COM objects COM_server.dll registered in Windows
• the sub folder is not on the system path.

Consider the following cases:

• app.exe calls LoadLibrary ("sub / regular.dll"). This will fail because Windows cannot find helper.dll according to the documented procedure for finding a DLL.
• app.exe calls CoCreateInstance to create an object implemented in com_server.dll. This succeeds and helper.dll loads.

Key questions: Why does the 2nd case work? What are the details of the dependent DLL lookup procedure for the COM server case?

It looks like when creating a com object with CoCreateInstance, the dll implementation folder is somehow added to the search path for dependencies. Is this what is happening and is it guaranteed? I cannot find any documentation anywhere where this case will be discussed.

Answer 1

See the documentation for LoadLibrary on MSDN :

If the string indicates the full path, the function searches only this path for the module. If the string indicates a relative path or module name without a path, the function uses the standard search strategy to find the module; see notes for more information.

Good, so that explains the behavior of # 1 above. If you would say:

 LoadLibrary("C:\\program files\\AppFolder\\Sub\\com_server.dll") 

Then it would find your dependent DLLs and the LoadLibrary succeeded.

As for how COM works C # 2 successfully, it really depends on how com_server.dll is registered in the registry for the InProcServer32 key. If this is the full path to the file, then LoadLibrary will work as described above. If this is a relative path, then I would suspect that COM can do any number of things to find DLL files like yours.

It is likely that CoCreateInstance is calling LoadLibraryEx with the LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR flag set . It can even call LoadLibrary (Ex) several times with a different combination of flags.

In addition, given that CoCreateInstance is a system API, it is possible that it has a private internal version of LoadLibrary that allows alternative search paths.