为什么在DllMain里不能调用LoadLibrary和FreeLibrary函数？
MSDN里对这个问题的答案十分的晦涩。不过现在我们已经有了足够的知识来解答这个问题。
考虑下面的情况：
(a)DllB静态链接DllA
(b)DllB在DllMain里调用DllA的一个函数A1()
(c)DllA在DllMain里调用LoadLibrary("DllB.dll")
分析：当执行到DllA中的DllMain的时侯，DllA.dll已经被映射到进程地址空间中，已经加入到了module list中。当它调用LoadLibrary("DllB.dll")时，首先会调用LdrpMapDll把DllB.dll映射到进程地址空间，并加入到InLoadOrderModuleList中。然后会调用LdrpLoadImportModule(...)加载它引用的DllA.dll，而 LdrpLoadImportModule会调用LdrpCheckForLoadedDll检查是否DllA.dll已经被加载。 LdrpCheckForLoadedDll会在哈希表LdrpHashTable中查找DllA.dll，而显然它能找到，所以加载DllA.dll这一步被成功调过。DllA在它的DllMain函数里能成功加载DllB，并要执行DllB的DllMain函数对其初始化。站在DllB的角度考虑，当程序运行到它的DllMain的时侯，它完全有理由相信它隐式链接的DllA.dll已经被加载并且成功地初始化。可事实上，此时DllA只是处在"正在初始化"的过程中!这种理想和现实的差距就是可能产生的Bug的根源，就是禁止在DllMain里调用LoadLibrary的理由!
本文附带的例子中说明了这种出错的情况：
TestLoad主程序： int main(int argc, char* argv[]) { HINSTANCE hDll = ::LoadLibrary( "DllA.dll" ) ; FreeLibrary( hDll ) ; return 0; } DllA： HANDLE g_hDllB = NULL ; char *g_buf = NULL ; BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: OutputDebugString( "==>DllA: Initialize begin! " ) ; g_hDllB = LoadLibrary( "DllB.dll" ) ; // g_buf在Load DllB.dll之后才初始化，显然它没有料到DllB在初始化时居然会用到g_buf!! g_buf = newchar[128] ; memset( g_buf, 0, 128 ) ; OutputDebugString( "==>DllA: Initialize end! " ) ; break ; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } returnTRUE; } DLLA_API void A1( char *str ) { OutputDebugString( "==>DllA: A1() " ) ; // 当DllB.dll在它的DllMain函数里调用A1()时，g_buf还没有初始化，所以必然会出错! strcat( g_buf, "==>DllA: " ) ; strcpy( g_buf, str ) ; OutputDebugString( g_buf ) ; } DllB： BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: OutputDebugString( "==>DllB: Initialize! " ) ; OutputDebugString( "==>DllB: DllB depend on DllA. " ) ; OutputDebugString( "==>DllB: I think DllA has been initialize. " ) ; // 当程序运行到这时，DllB认为它引用的DllA.dll已经加载并初始化了，所以它调用DllA的函数A1() A1( "DllB Invoke DllA::A1() " ) ; break ; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } returnTRUE; }
在调用DllA的函数A1()时，因为DllA里有些变量还没初始化，所以会产生exception。以下是截取的部分LDR的输出，"==>"开头的是程序的输出。
LDR: Loading (DYNAMIC) H:cmvc6TestLoadinDllA.dll
LDR: KERNEL32.dll used by DllA.dll
LDR: Snapping imports for DllA.dll from KERNEL32.dll
LDR: Real INIT LIST
H:cmvc6TestLoadinDllA.dll init routine 10001440
LDR: DllA.dll loaded. - Calling init routine at 10001440
==>DllA: Initialize begin!
LDR: Loading (DYNAMIC) H:cmvc6TestLoadinDllB.dll
LDR: DllA.dll used by DllB.dll
LDR: Snapping imports for DllB.dll from DllA.dll
LDR: Refcount DllA.dll (2)
LDR: Real INIT LIST
H:cmvc6TestLoadinDllB.dll init routine 371260
LDR: DllB.dll loaded. - Calling init routine at 371260
==>DllB: Initialize!
==>DllB: DllB depend on DllA.
==>DllB: I think DllA has been initialize.
==>DllA: A1()
First-chance exception in Test.exe (DLLA.DLL): 0xC0000005: Access Violation.
==>DllA: Initialize end!
在前面已经说过LdrUnloadDll里对DllMain里调用FreeLibrary的情况进行了特殊处理。此时仍然会对各个相关的Dll引用计数减 1，并移入到unload list中，但然后LdrUnloadDll就返回了!并没有执行Dll的termination code。我构建了一个运行正确的例子TestUnload，说明LdrUnloadDll是怎么处理的。
考虑下面的情况：
(a)DllA依赖于DllC，DllB也依赖于DllC
(b)DllA里调用LoadLibrary("DllB.dll")，并保证其成功
(c)DllA在DllMain的termination code里执行FreeLibrary()，释放DllB
(d)在主程序里动态的加载DllA
下面的代码和注释说明了程序运行的细节：
TestUnload主程序： int main(int argc, char* argv[]) { HINSTANCE hDll = ::LoadLibrary( "DllA.dll" ) ; // 在调用LoadLibrary之后 // LoadOrderList: A(1) --> C(2) --> B(1), 括号内的代表LoadCount // MemoryOrderList: A(1) --> C(2) --> B(1) // InitOrderList: C(2) --> A(1) --> B(1) FreeLibrary( hDll ) ; return 0; } DllA: BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: OutputDebugString( "==>DllA: Initialize! " ) ; // 这里用LoadLibrary是安全的 g_hDllB = LoadLibrary( "DllB.dll" ) ; if (NULL == g_hDllB) returnFALSE ; break ; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: break ; case DLL_PROCESS_DETACH: // 运行到这里时，DllA现在只留在LoadOrderList中，已经从另两个list中删除 // LoadOrderList: A(0) --> C(1) --> B(1) // MemoryOrderList: C(1) --> B(1) // InitOrderList: C(1) --> B(1) OutputDebugString( "==>DllA: Uninitialize begin! " ) ; FreeLibrary( g_hDllB ) ; // 运行到这里时，DllB和DllC都从MemoryOrderList和InitOrderList中删除了 // LoadOrderList: A(0) --> C(0) --> B(0) // MemoryOrderList: // InitOrderList: OutputDebugString( "==>DllA: Uninitialize end! " ) ; break; } returnTRUE; }
如果主程序是静态链接DllA又如何呢？LdrUnloadDll同样能判断这种情况：如果进程正在关闭那么LdrUnloadDll直接返回。我也构建了一个运行正确的例子TestUnload2来说明这种情况：
TestUnload2主程序： int main(int argc, char* argv[]) { // 此时DllA,DllB,DllC均已load // LoadOrderList: A(-1) --> C(-1) --> B(1), 括号内的代表LoadCount // MemoryOrderList: A(-1) --> C(-1) --> B(1) // InitOrderList: C(-1) --> A(-1) --> B(1) return 0; } DllA: BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: OutputDebugString( "==>DllA: Initialize! " ) ; // 这里用LoadLibrary是安全的 g_hDllB = LoadLibrary( "DllB.dll" ) ; if (NULL == g_hDllB) returnFALSE ; break ; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: break ; case DLL_PROCESS_DETACH: // 运行到这里时，DllB已经被卸载，因为它是InitOrderList中最后一项 // 这里的卸载指的是调用了Init routine，发出了DLL_PROCESS_DETACH通知，而不是指unmap内存中的映像 OutputDebugString( "==>DllA: Uninitialize begin! " ) ; // 这里不应该再调用DllB的函数!!! // 尽管DllB已经被卸载，但这里调用FreeLibrary并无危险 // 因为LdrUnloadDll判断出进程正在Shutdown，所以它什么也没做，直接返回 FreeLibrary( g_hDllB ) ; OutputDebugString( "==>DllA: Uninitialize end! " ) ; break; } returnTRUE; }
在Jeffrey Richter的"Windows核心编程"和Matt Pietrek在1999年MSJ上的"Under theHood"里都说到，User32.dll在它的initializecode里会用LoadLibrary加载 "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrentVersionWindowsAppInit_DLLs" 下的dll，在它的terminate code里会用FreeLibrary卸载它们。跟踪它的FreeLibrary函数，发现同上面的例子一样，LdrUnloadDll发现进程正在 Shutdown中，就直接返回了，没有任何危险。(User32.dll是静态链接的函数，只可能在进程关闭时被卸载。另外，在我调试的时侯，发现即使 AppInit_DLLs下为空，User32.dll仍然会加载imm32.dll)。
总而言之，FreeLibrary本身是相当安全的，但MSDN里对它的警告也并非是胡说八道。在DllMain里使用FreeLibrary仍然是具有危险性的，与LoadLibrary一样，它们具有相同的Bug哲学，即理想和现实的差距!
TestUnload2虽然运行正确，但是它具有潜在的危险性。
对DllA而言，释放DllB是它的责任，是它在收到DLL_PROCESS_DETACH通知之后用FreeLibrary卸载的，可事实上如果DllA被主程序静态链接，或者DllA是动态链接但没有用FreeLibrary显式卸载它的话，那么在进程结束时，在DllA卸载DllB之前，DllB就已经被主程序卸载掉了!这种认识上的错误就是养育Bug的沃土。如果DllA没有认识到这种可能性，而在FreeLibrary之前调用DllB的函数，就极可能出错!!!
为了加深理解，我用文章开头提到的那个Bug来说明这种情况，那可是血的教训。问题描述如下：
我用MFC写了一个OCX，OCX里动态加载了一些Plugin Dlls，在OCX的ExitInstance(相当于DllMain里处理DLL_PROCESS_DETACH通知)里调用这些Plugin的 Uninitialize code，然后用FreeLibrary将其释放。在我用MFC编写的一个Doc/View架构的测试程序里运行良好，但不久客户就报告了一个Bug：用 VB写了一个OCX2来包装我的OCX，在一个网页里使用OCX2，然后在IE里打开这个网页，在关掉IE时会当掉!发生在特定条件下的奇怪的错误!当时我可是费了不少功夫来解这个Bug，现在一切都那么清晰了。
下面是我用MFC写的测试程序在关闭时的堆栈：
PDFREA_1!CPDFReaderOCXApp::ExitInstance+0x1d PDFREA_1!DllMain+0x1bb PDFREA_1!_DllMainCRTStartup+0x80 ntdll!LdrpCallInitRoutine+0x14 ntdll!LdrUnloadDll+0x29a KERNEL32!FreeLibrary+0x3b ole32!CClassCache::CDllPathEntry::CFinishObject::Finish+0x2b ole32!CClassCache::CFinishComposite::Finish+0x19 ole32!CClassCache::FreeUnused+0x192 ole32!CoFreeUnusedLibraries+0x35 MFCO42D!AfxOleTerm+0x7b MFCO42D!AfxOleTermOrFreeLib+0x12 MFC42D!AfxWinTerm+0xa9 MFC42D!AfxWinMain+0x103 ReaderContainerMFC!WinMain+0x18 ReaderContainerMFC!WinMainCRTStartup+0x1b3 KERNEL32!BaseProcessStart+0x3d
可以看到OCX被FreeLibrary显式地释放，抢在Plugin被进程释放之前，所以不会出错。
下面是关闭IE时的堆栈：
CPDFReaderOCXApp::ExitInstance() line 44 DllMain(HINSTANCE__ * 0x04e10000, unsigned long 0, void * 0x00000001) line 139 _DllMainCRTStartup(void * 0x04e10000, unsigned long 0, void * 0x00000001) line 273 + 17 bytes NTDLL! LdrShutdownProcess + 238 bytes KERNEL32! ExitProcess + 85 bytes
可以看到OCX是在LdrShutdownProcess里被释放的，而此时Plugin已经被释放掉了，因为在 InInitializationOrderModuleList表里Plugin Dlls在OCX之后，所以它们被先释放!这种情况要是还不出错真是奇迹了。
总结：虽然MS警告不要在DllMain里不能调用LoadLibrary和FreeLibrary函数，可实际上它还是做了很多的工作来处理这种情况。只不过因为他不想或者懒得说清楚到底哪些情况不能这么用，才干脆一棒子打死统统不许。在你自己的程序里不是绝对不能这么用，只是你必须清楚地知道每件事是怎么发生的，以及潜在的危险。
- DllMain函数中不能Load（Unload）别的dll；
- DllMain函数中不能调用其它dll暴露的函数！（System32.dll、User32.dll、Advapi32.dll除外）
- Dll中声明的全局（或静态）变量的构造和析构函数中同样不能执行以上的操作！因为这些函数甚至在DllMain执行之前就已经执行了！