调试实战 —— dll 加载失败之全局变量初始化篇
前言
最近項目里總是遇到 dll 加載不上的問題，原因各種各樣。今天先總結(jié)一個雖然不是項目中實際遇到的問題，但是卻非常經(jīng)典的問題。其它幾種問題，后續(xù)慢慢總結(jié)。
示例代碼包含一個 exe 工程，兩個 dll 工程。exe 會加載兩個 dll 并調(diào)用它們的導(dǎo)出函數(shù)（GetCallCount），結(jié)果只有一個 dll 的導(dǎo)出函數(shù)被成功調(diào)用。會是什么原因呢？
現(xiàn)象
運行效果如下圖：
run_result通過 dumpbin 已經(jīng)確認(rèn)兩個 dll 都有名為 GetCallCount 的函數(shù)。但是只有一個調(diào)用成功了，另外一個卻調(diào)用失敗。
dumpbin-exports使用 process explorer 觀察 dll 加載情況，發(fā)現(xiàn)只加載了一個 dll，沒發(fā)現(xiàn)另外一個 dll。
loaded_dll對于這個問題，如果我們使用 procmon 觀察整個加載過程，看到的都是 Success。如下圖：
procmon-trace說明，加載正常，在本地找到了這個文件，并正確的映射到內(nèi)存空間中了。但為什么在進程中觀察不到這個 dll 呢？是時候上調(diào)試器了。
上調(diào)試器
直接在 vs 中按 F5 啟動，果然中斷到 vs 中了。
exception-and-call-stack從上圖右側(cè)部分，我們可以看到完整的調(diào)用棧。
這里簡單介紹下相關(guān)代碼。在 GlobalVariableInitializeOrder.cpp 的第 15 行調(diào)用了 HMODULE hDll2 = LoadLibraryA("GlobalVariableInitializeOrderDll2.dll"); 加載對應(yīng)的模塊。
Common\Test2.cpp 的第 10 行定義了全局變量 CTest2 g_t2;，問題就出在這個全局變量的初始化代碼中。
從上圖左側(cè)部分，我們可以得知錯誤代碼是 0xc0000005，內(nèi)存訪問異常。訪問的地址是 0x00000004，對應(yīng)的指令位置是 0x001EA6DB。
invalid-eax從上圖中的反匯編看，確實是掛在了 001EA6DB mov eax,dword ptr [eax]。因為 eax 的值是 4，我們需要查明 eax 為什么的值是 4。相信很多小伙伴都知道，eax 用來保存函數(shù)調(diào)用的返回值。我們可以把注意力集中到 0x001EA6D6 處的 call 指令了，調(diào)用的是成員函數(shù) _Root() 。
查看 vs 提供的源碼，如下：
_Nodeptr&?_Root()?const {?//?return?root?of?nonmutable?treereturn?(this->_Parent(this->_Myhead)); }我們可以發(fā)現(xiàn) _Root() 內(nèi)部簡單的調(diào)用了 _Parent() 函數(shù)，并把 this->_Myhead 當(dāng)作參數(shù)傳遞過去了。再查看下 _Parent() 函數(shù)的源碼，如下：
static?_Nodepref?_Parent(_Nodeptr?_Pnode) {?//?return?reference?to?parent?pointer?in?nodereturn?((_Nodepref)_Pnode->_Parent); }務(wù)必注意： _Parent() 的返回值類型是 _Nodepref，返回的是引用（最后三個字母 ref 已經(jīng)說明了一切）！相當(dāng)于返回的是 _Pnode->_Parent 的地址！我們可以查看 _Nodepref 的定義：typedef _Nodeptr& _Nodepref;。
所以 _Root() 函數(shù)相當(dāng)于 &(this->_Myhead->_Parent)。我們來觀察下 this 的值。
watch-this-value可以看到 _Myhead 的值是 0，類型是 std::_Tree_node<...>。
我們再看下 _Tree_node 的定義：
template<class?_Value_type,?class?_Voidptr> struct?_Tree_node {_Voidptr?_Left;?????//?offset:?0x0_Voidptr?_Parent;???//?offset:?0x4_Voidptr?_Right;????//?offset:?0x8char?_Color;????????//?offset:?0xCchar?_Isnil;????????//?offset:?0xD_Value_type?_Myval;?//?offset:?0x10private:_Tree_node&?operator=(const?_Tree_node&); };從 _Tree_node 的定義可知， _Parent 的偏移是 4 （因為是 32 位的程序，如果是 64 位，那么是 8）。
綜上，地址 001EA6D6 處的 call 指令反回了 4。接下來的兩條指令是把返回值賦給局部變量 _Nodeptr _Pnode。但是在執(zhí)行第一條匯編指令 ?mov eax,dword ptr [eax] 時就掛了，因為 eax 的值是 4，正常情況下訪問 0x00000004 處的值當(dāng)然會掛掉了。
至此，我們知道了崩潰的直接原因——訪問非法地址。但是根本原因是什么呢？為什么 _Myhead 是 0 呢？我猜測是因為 map 還沒有初始化。但是該如何證實這個猜測呢？
繼續(xù)深入
CTest2 的構(gòu)造函數(shù)里調(diào)用的是 CTest1::GetMap()，GetMap() 內(nèi)部會返回 CTest1 的靜態(tài)變量 static std::map<std::string, std::string> s_manager; 的引用。
如果能證明在 CTest2::g_t2 初始化時，CTest1::s_manager 還沒初始化，那么我們就證實了我們的猜測。
我想到兩個辦法：
在 ?map 的構(gòu)造函數(shù)中輸出一條日志。在調(diào)用 g_t2 的構(gòu)造函數(shù)時，查看是否有我們在 map 中新加的日志。
明確每個全局變量的初始化順序。
第一種方法比較簡單，直接修改 vs 提供的源碼即可，注意修改只讀屬性。本文以第 2 種方法為例展開。
全局變量初始化簡介
本小節(jié)根據(jù)上面的調(diào)用棧簡單的介紹全局變量的初始化過程（只介紹我們關(guān)心的部分）。
不知道各位小伙伴兒是否記得上面的調(diào)用棧。切換到 8 號棧幀，如下圖：
__DllMainCRTStartup-call-_CRT_INIT可以發(fā)現(xiàn)，在 __DllMainCRTStartup() 函數(shù)中，當(dāng) dwReason == DLL_PROCESS_ATTACH 或者 dwReason == DLL_THREAD_ATTACH 的時候，會調(diào)用 _CRT_INIT() 函數(shù)。_CRT_INIT() 會執(zhí)行運行時庫的初始化相關(guān)功能，比如，初始化全局變量。然后才會調(diào)用用戶提供的 DllMain() 函數(shù)。
繼續(xù)切換到 7 號棧幀，如下圖：
crt_init通過注釋可知，_initterm() 是在調(diào)用 C++ constructors。
我們繼續(xù)切換到 6 號棧幀，如下圖：
_initterm根據(jù)注釋猜測，應(yīng)該是在依次調(diào)用每個全局變量的初始化函數(shù)。pfbegin 指向了保存全局變量初始化函數(shù)的表格的起始位置，pfend 指向最后一個有效位置的下一個位置，跟標(biāo)準(zhǔn)庫中的容器多么相似啊。如果 *pfbegin 的值不為 0，說明表格對應(yīng)的位置有有效的初始化函數(shù)，需要調(diào)用，否則就跳過。
在 vs 中，我們想遍歷出這個表格的內(nèi)容有些費勁。是時候請 windbg 出場了。
windbg 出場
在使用 windbg 之前一定要設(shè)置好符號路徑，否則很多內(nèi)容看不到。
使用 windbg 打開要運行的程序，在命令窗口輸入 bm GlobalVariableInitializeOrderDll2!_CRT_INIT ，埋伏好斷點后執(zhí)行 g 命令繼續(xù)運行。
set-breakpoint-by-bm很快，就中斷到我們設(shè)置好的斷點處了。在調(diào)用 _initterm() 的地方設(shè)置好斷點，執(zhí)行 g 命令（也可以和 vs 一樣按 F5），斷下來后，單步進入 _initterm() 函數(shù)，執(zhí)行 dv 查看局部變量。
single-step-to-initterm從輸出結(jié)果可知，pfbegin = 0x001f6000，pfend = 0x001f6250。然后我們就可以用強悍的 dps 來查看pfbegin 和 pfend 之間的內(nèi)容了。在命令窗口執(zhí)行，dps 0x001f6000 0x001f6250。因為有很多空項，這里只截取中間部分。
dps-0x001f6000-0x001f6250我們可以很明顯的看到，g_t2的構(gòu)造函數(shù)在前，s_manager 的構(gòu)造函數(shù)在后。
至此，已經(jīng)證實了我們之前的猜想。
對比強化
因為工程 GlobalVariableInitializeOrderDll1 和工程 GlobalVariableInitializeOrderDll2 代碼一模一樣，只有一點點的不同，就是這一點不同導(dǎo)致了一個 dll 可以正常使用，另外一個卻不能正常使用。
我們可以用相同的手法觀察 GlobalVariableInitializeOrderDll1.dll 的初始化過程。
在命令窗口輸入 bm GlobalVariableInitializeOrderDll1!_CRT_INIT;g ，埋伏好斷點后運行起來。再次中斷后，使用相同的辦法進入_initterm() 函數(shù)，通過 dv 命令得到 pfbegin = 0x10026000 和 pfend = 0x10026250 的值，然后執(zhí)行 dps 0x10026000 0x10026250，如下圖（同樣有很多空項，只截取了中間部分）：
我們發(fā)現(xiàn)，s_manager 的構(gòu)造函數(shù)在前，g_t2的構(gòu)造函數(shù)在后。
修復(fù)
我們應(yīng)該從根本上消除對全局變量的依賴，只需要把 s_manager 放到 GetMap() 中就可以了。
static?std::map<std::string,?std::string>&?GetMap() {static?std::map<std::string,?std::string>?s_manager;return?s_manager; }但有時候，由于各種各樣的原因，我們不能消除這種依賴。我們還可以調(diào)整全局變量的初始化順序。只要有辦法讓 g_t2 在 s_manager 之后再初始化就可以了。對比兩個 dll 工程文件，我們發(fā)現(xiàn)有一處關(guān)鍵的不同點。
difference-of-project1-2在能正常加載的 dll 對應(yīng)的工程中， Test1.cpp, Test2.cpp 出現(xiàn)的順序是 Test1.cpp, Test2.cpp，在不能正常加載的 dll 對應(yīng)的工程中，出現(xiàn)的順序是 Test2.cpp, Test1.cpp。調(diào)整 dll2.vcxproj 中的文件順序和 dll1.vcxproj 一樣，再次編譯運行，一切順利。
success動手實戰(zhàn)
強烈建議你也動手實戰(zhàn)一番，畢竟紙上來的終覺淺。如果你也想動手實戰(zhàn)，可以下載完整的工程文件，使用 vs2013 編譯運行即可。如果沒裝 vs2013，也可以手動改成其它版本的 vs。
完整的測試工程下載鏈接：
百度云 鏈接: https://pan.baidu.com/s/1gW1dZsNYZoo0s_rfaO2Jzg 提取碼: 7irh
CSDN 鏈接：https://download.csdn.net/download/xiaoyanilw/12405380
總結(jié)
永遠(yuǎn)不要讓一個全局變量依賴另外一個全局變量。
全局變量是在 DllMain 或者 main 函數(shù)執(zhí)行前進行初始化的。
在?32?位程序中，一般使用?eax?保存函數(shù)的返回值。
dps 命令可以按地址遍歷給定范圍的內(nèi)容。
dv 命令可以查看局部變量和參數(shù)。
參考資料
如果有小伙伴兒對全局變量初始化感興趣，可以參考以下幾篇文檔：
https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-initialization?redirectedfrom=MSDN&view=vs-2019
http://www.cppblog.com/xlshcn/archive/2007/12/07/37088.html
http://bytepointer.com/resources/pietrek_libctiny_2001.htm
需要你的
總結(jié)
以上是生活随笔為你收集整理的调试实战 —— dll 加载失败之全局变量初始化篇的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [开源] .Net orm FreeSq
- 下一篇： Sql Server之旅——第七站 复合