Alterando a ordem de carregamento de DLL do Windows? (ordem de carregamento, não ordem de pesquisa)

Digamos que eu tenha um executável: app.exe

Eu uso 2 DLLs de terceiros diferentes neste executável: foo.dll bar.dll e o aplicativo deve estar vinculado implicitamente a essas DLLs, ou seja, não posso usar :: LoadLibrary para carregá-los.

(Observação: não é que eu não possa chamar LoadLibrary , mas essas DLLs requerem vinculação estática (DLLs C ++ com __ declspec (dllexport) ), então chamar LoadLibrary não faz sentido porque o carregador executável já o chamou.)

Essas duas DLLs não têm dependências uma da outra, ou seja,sua ordem de carregamento é indefinida, tanto quanto eu posso dizer (e deve ser irrelevante). (As dependências de ambos são basicamente apenas nas dlls padrão do Windows (kernel32, msvcrt, etc.)

Agora tenho o problema de que desejo controlar a ordem de carregamento dessas DLLs, ou seja, desejo que foo.dll seja sempre carregado ( DLL_PROCESS_ATTACH ) antes de bar.dll.

É de alguma forma possível dizer ao Windows DLL Loader para carregar uma DLL antes de outra?

Editar: Para verifique a ordem de carregamento da DLL de um executável, pode-se usar o utilitário DUMPBIN.exe : (Basta iniciar o Prompt de comando do Visual Studio)

Editar: De acordo com esta resposta / esta entrada de blog , o NT Loader percorre a seção de importação sequencialmente. (O que resultará em independentes DLLs sendo carregadas na ordem em que aparecem no seção de importação.)

C:\path\to\program> dumpbin /IMPORTS app.exe | grep -i \.dll
  MSVCR80D.dll
  KERNEL32.dll
  OLEAUT32.dll
  MSVCP80D.dll
  foo.dll
  bar.DLL

Esta saída significa que MSVCR80D.dll (e suas dependências ^[a] ) serão carregados primeiro e que bar.DLL será carregado por último. pt na ordem inversa.

O que eu não descobri ainda é como influenciar esta ordem de carregamento ...

(Notas)

[a]: Isso significa, é claro, que, por exemplo kernel32.dll será carregado primeiro, porque msvcr80d.dll dependerá de kernel32.dll.

De acordo com algumas solicitações, estou adicionando uma justificativa para isso: _{(Mas por favor , eu estou ainda interessado nisso em geral. Eu sei como contornar o problema do MFC. )}

O Microsoft MFC DLL em sua versão de depuração tem detecção de vazamento de memória embutida. ( Pelo que eu posso dizer, é o mesmo mecanismo usado por _CrtSetDbgFlag e ferramentas relacionadas.)

A DLL de depuração do MFC irá despejar toda a memória não liberada quando ela for descarregada. Agora, se você tiver uma segunda DLL em seu processo, que é independente do MFC, e essa segunda DLL desalocar memória em DLL_PROCESS_DETACH, o mecanismo de relatório do MFC relatará falsos vazamentos de memória, se a DLL do MFC for descarregada antes da outra dll.

Se alguém pudesse ter certeza de que a DLL do MFC de depuração é carregada primeiro / descarregada por último de todas as DLLs independentes, todas as outras DLLs já teriam sido limpas depois de si mesmas e o MFC não relataria vazamentos falsos.