title: Changing Windows DLL load order? (load order, not search order)
body: <p>Say I have one executable: <code>app.exe</code></p>
  
  <p>I use 2 different 3rd party DLLs in this executable: <code>foo.dll</code> <code>bar.dll</code> and the Application must link implicitly to these DLLs, that is I cannot use <code>::LoadLibrary</code> to load them.</p>
  
  <p>(Note: It's not that I cannot call <code>LoadLibrary</code>, but these DLLs require static linking (C++ DLLs with <code>__declspec(dllexport)</code>), so me calling <code>LoadLibrary</code>doesn't make any sense because the excutable loader has already called it.)</p>
  
  <p>These two DLLs do <em>not</em> have any dependencies on each other, that is, their load order is undefined as far as I can tell (and <em>should</em> be irrelevant). (Dependencies of both are basically only on the standard windows dlls (kernel32, msvcrt, etc.)</p>
  
  <p>I now have the problem that I wish to control the load order of these DLLs, that is I wish that foo.dll is <em>always</em> loaded (<code>DLL_PROCESS_ATTACH</code>) before bar.dll.</p>
  
  <p>Is it somehow possible to tell the Windows DLL Loader to load one DLL before another?</p>
  
  <p>Edit: To <strong>check the DLL load order</strong> of an executable, one can use the <code>DUMPBIN.exe</code> utility: (Just launch the Visual Studio Command Prompt)</p>
  
  <p>Edit: As per <a href="https://stackoverflow.com/questions/6382560/does-the-nt-dll-loader-load-dlls-in-the-order-of-the-import-section-of-the-execut/6383562#6383562">this answer</a> / <a href="https://docs.microsoft.com/en-us/archive/blogs/mgrier/the-nt-dll-loader-basic-operation" rel="nofollow noreferrer">this blog entry</a>, the NT Loader <em>does</em> walk the import section sequentially. (Which will result in <em>independent</em> DLLs being loaded in the order they appear in the import section.)</p>
  
  <pre><code>C:\path\to\program&gt; dumpbin /IMPORTS app.exe | grep -i \.dll
    MSVCR80D.dll
    KERNEL32.dll
    OLEAUT32.dll
    MSVCP80D.dll
    foo.dll
    bar.DLL
  </code></pre>
  
  <p>This output means that MSVCR80D.dll (and its dependecies<sup>[a]</sup>) will be loaded first and that bar.DLL will be loaded last. Unload will happen in reverse order.</p>
  
  <p>What I <em>haven't</em> found out yet is <strong>how to influence this load order</strong> ...</p>
  
  <hr>
  
  <p>(Notes)</p>
  
  <p>[a] : This means of course that e.g. kernel32.dll will be loaded first, because msvcr80d.dll will depend on kernel32.dll.</p>
  
  <hr>
  
  <p>As per some requests, I'm adding a rationale for this: <sub>(But <strong>please</strong>, I'm <em>still</em> interested in this generally. <em>I know how to work around the MFC problem.</em>)</sub></p>
  
  <p>The Microsoft MFC DLL in it's debug version has memory leak detection built in. (As far as I can tell, it's the same mechanism used by <a href="http://msdn.microsoft.com/en-us/library/5at7yxcs%28v=VS.80%29.aspx" rel="nofollow noreferrer">_CrtSetDbgFlag</a> and related tools.)</p>
  
  <p>The MFC debug DLL will dump all unfreed memory when it is unloaded. Now, if you have a second DLL in your process, that is independent of MFC, and this second DLL deallocates memory on DLL_PROCESS_DETACH, the MFC reporting mechanism will report false memory leaks, if the MFC DLL is unloaded before the other dll.</p>
  
  <p>If one could make sure that the debug MFC DLL is loaded first / unloaded last of all independent DLLs, then all other DLLs would already have cleaned up after themselves and MFC wouldn't report false leaks.</p>