{"id":95265,"date":"2017-01-26T07:00:00","date_gmt":"2017-01-26T22:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=95265"},"modified":"2019-03-13T01:05:12","modified_gmt":"2019-03-13T08:05:12","slug":"20170126-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20170126-00\/?p=95265","title":{"rendered":"How can I control the directory from which my delay-loaded DLL is loaded?"},"content":{"rendered":"

A customer had a DLL that is a COM in-process server. This DLL gets loaded by arbitrary client applications, and it also uses the \/DELAYLOAD<\/code> linker flag to delay-load many of the DLLs which it depends upon. The customer observed that these delay-loaded DLLs were being loaded according to the standard DLL-loading search algorithm.¹ The problem is that the DLL which they are dependent upon is not in the standard search path; it’s in its own private directory. <\/p>\n

The customer explained that they are working around this problem by providing a custom delay-load helper function<\/a> which calls Set­Dll­Directory<\/code> to add the private directory to the DLL search path. <\/p>\n

The customer wanted to know whether Set­Dll­Directory<\/code> affects the DLL search path for the entire process. The customer doesn’t want to affect the DLL search path for the entire process because the DLL is a guest in the host process<\/a>, so it shouldn’t be changing the carpet<\/a>. (Hey, at least they’re not calling in a demolition team<\/a>.) “If it affects only the DLL we need to load, then it looks like Set­Dll­Directory<\/code> is what we need. But if it affects the entire process, then we would have to switch to Add­Dll­Directory<\/code>.” <\/p>\n

Yes, the Set­Dll­Directory<\/code> function affects the DLL search path for the entire process. It’s not clear what the customer’s mental model is for “affects only the DLL we need to load”, seeing as you don’t actually pass Set­Dll­Directory<\/code> the name of the DLL you need to load, so it has no idea which DLL to apply this path to. <\/p>\n

The customer’s proposed alternative of using Add­Dll­Directory<\/code> doesn’t solve the problem, because it too affects the DLL search path for the entire process. Maybe they were thinking of calling Add­Dll­Directory<\/code> to add the private directory, then calling Remove­Dll­Directory<\/code> to remove it at some unspecified point in the future. But that creates a window in which the process DLL path has the private directory, and if another thread also calls Load­Library<\/code>, it will see that other private directory, which is presumably unwanted. <\/p>\n

The customer is making things too hard for themselves by manipulating the DLL search paths. Since they know what directory the DLL is in, they don’t need to do any searching at all. When the notification handler is called, it is given a few pieces of information<\/a>. <\/p>\n