DllMain中不當操作導致死鎖問題的分析——DllMain中要謹慎寫代碼（完結篇）

之前幾篇文章主要介紹和分析了爲什麼會在DllMain做出一些不當操作導致死鎖的原因。本文將總結以前文章的結論，並介紹些DllMain中還有哪些操作會導致死鎖等問題。（轉載請指明出於breaksoftware的csdn博客）
        DllMain的相關特性

        首先列出《DllMain中不當操作導致死鎖問題的分析--進程對DllMain函數的調用規律的研究和分析》中論證的11個特性：

1. Dll的加載不會導致之前創建的線程調用其DllMain函數。
   
2. 線程創建後會調用已經加載了的DLL的DllMain，且調用原因是DLL_THREAD_ATTACH。(DisableThreadLibraryCalls會導致該過程不被調用)
   
3. TerminateThread方式終止線程是不會讓該線程去調用該進程中加載的Dll的DllMain。
   
4. 線程正常退出時，會調用進程中還沒卸載的DLL的DllMain，且調用原因是DLL_THREAD_DETACH。
   
5. 進程正常退出時，會調用（不一定是主線程）該進程中還沒卸載的DLL的DllMain，且調用原因是DLL_PROCESS_DETACH。
   
6. 加載DLL進入進程空間時(和哪個線程LoadLibrary無關)，加載它的線程會調用DllMain，且調用原因是DLL_PROCESS_ATTACH。
   
7. DLL從進程空間中卸載出去前，會被卸載其的線程調用其DllMain，且調用原因是DLL_PROCESS_DETACH。
   
8. TerminateProcess 將導致線程和進程在退出時不對未卸載的DLL進行DllMain調用。
   
9. ExitProcess將導致主線程意外退出，子線程對未卸載的DLL進行了DllMain調用，且調用原因是DLL_PROCESS_DETACH。
10. ExitThread是最和平的退出方式，它會讓線程退出前對未卸載的DLL調用DllMain。
    
11. 線程的創建和退出不會對調用了DisableThreadLibraryCalls的DLL調用DllMain。

        不要在DllMain中做的事情

• A 直接或者間接調用LoadLibrary(Ex)

        假如我們在A.dll中的DllMain收到DLL_PROCESS_ATTACH時，加載了B.dll；而B.dll中的DllMain在收到DLL_PROCESS_ATTACH時又去加載A.dll。則產生了循環依賴。但是注意不要想當然認爲這個過程是A.dll的DllMain調用了B.dll的DllMain，B.dll的DllMain再調用了A.dll的DllMain這樣的死循環。即使不出現循環依賴，如果出現《DllMain中不當操作導致死鎖問題的分析——線程中調用GetModuleFileName、GetModuleHandle等導致死鎖》中第三個例子的情況，也會死鎖的。

• B 使用CoInitializeEx

        在CoInitializeEx底層會調用LoadLibraryEx，原因同A。

• C 使用CreateProcess

        CreateProcess在底層執行了加載DLL的操作。我用IDA查看Kernel32中的CreateProcess可以發現其底層調用的CreateProcessInternalW中有

• D 使用User32或Gdi32中的函數

        User32和Gdi32中部分函數在調用的底層會加載其他DLL。

• E 使用託管代碼

        運行託管代碼需要加載其他DLL。

• F 與其他線程同步執行

        由《DllMain中不當操作導致死鎖問題的分析--加載卸載DLL與DllMain死鎖的關係》、《DllMain中不當操作導致死鎖問題的分析--導致DllMain中死鎖的關鍵隱藏因子》和《DllMain中不當操作導致死鎖問題的分析--線程退出時產生了死鎖》可知，進程創建和銷燬以及DLL的加載都要進入PEB的LoadLock臨界區。如果佔用了LoaderLock臨界區的線程在等待一個需要經過臨界區才能結束的線程時，就發生了死鎖。以上3篇博文中均有案例。

• G 同步對象

         如果該同步對象的釋放需要獲得PEB中的LoaderLock，而佔用該臨界區的線程又要去等待這個同步對象，則會死鎖。其實F中的線程也算是個同步對象。案例詳見《DllMain中不當操作導致死鎖問題的分析——線程中調用GetModuleFileName、GetModuleHandle等導致死鎖》中例子。

• H 使用CreateThread

        理由同F。

• I 使用ExitThread

        理由同F。

• J 寄希望於DisableThreadLibraryCalls解決死鎖問題

        由《DllMain中不當操作導致死鎖問題的分析--DisableThreadLibraryCalls對DllMain中死鎖的影響》可知。DisableThreadLibraryCalls的實現邏輯是：找到PEB結構中用於保存加載器信息的結構體對象Ldr。

        Ldr對象的InMemoryOrderModuleList用戶保存已經加載的DLL的鏈表。

        它遍歷這個鏈表，找到調用DisableThreadLibraryCalls的DLL的信息，將該信息中的Flags字段設置或上0x40000。

        而創建線程在底層將調用LdrpInitializeThread(詳見《DllMain中不當操作導致死鎖問題的分析--DisableThreadLibraryCalls對DllMain中死鎖的影響》)。該函數一開始便進入了PEB中LoaderLock臨界區，在該臨界區中根據PEB中LDR的InMemoryOrderModuleList遍歷加載的DLL，然後判斷該DLL信息的Flags字段是否或上了0x40000。如果或上了，就不調用DllMain。如果沒或上，就調用DllMain。這說明DisableThreadLibraryCalls對創建線程時是否進入臨界區無關。

        在退出線程時底層將調用LdrShutdownThread（詳見《DllMain中不當操作導致死鎖問題的分析--線程退出時產生了死鎖》）。該函數邏輯和LdrpInitializeThread相似，只是在調用DllMain時傳的是DLL_THREAD_DETACH。所以DisableThreadLibraryCalls對LdrShutdownThread是否進入臨界區也是沒有影響的。