《Windows 用戶態程序高效排錯》市場價元 特價元 購買>>
這裡直接把 ebx推入stack然後調用std::cout並沒有讀取stack中的資料說明func_template（callee）認為參數應該是從寄存器中傳入的然而transform函數（caller）卻把參數通過stack傳遞於是使用transform調用func_template的時候func_template無法拿到正確的參數因而導致崩潰通過for loop調用的時候由於參數通過寄存器傳遞所以func_template就可以正常工作
結論是編譯器對參數的傳入讀取處理不統一導致了這個問題
為何問題在debug模式下不發生或者調換函數次序後也不發生留作你的練習吧 :P
案例分析臭名昭著的DLL Hell如何導致ASPNET出現Server Unavailable
客戶的ASPNET程序訪問任何頁面都報告 Server Unavailable觀察發現ASPNET的宿主wwpexe進程每次剛啟動就崩潰通過調試器觀察崩潰的原因是訪問了一個空指針但是從 call stack看這裡所有的代碼都是wwpexe和net framework的代碼還沒有開始執行客戶的頁面所以跟客戶的代碼無關通過代碼檢查發現該空指針是作為函數參數從調用者（caller）傳到被調用者（callee）的當callee使用這個指針的時候問題發生接下來應該檢查caller為什麼沒有把正確的指針傳入callee
奇怪的時候caller中這個指針已經正常初始化了是一個合法的指針調用call語句執行callee的以前這個指針已經被正確地push到stack上了為什麼caller從stack上拿的時候卻拿到一個空指針呢？再次單步跟蹤發現問題在於caller把參數放到了callee的［ebp+］但是callee在使用這個參數的時候卻訪問［ebp+c］是不是跟前一個案例很像？但是這次的凶手不是編譯器而是文件版本Caller和callee的代碼位於兩個不同的DLL其中caller是NET Framework 帶的而callee是NET Framework SP帶的在NET Framework 中callee函數接受個參數但是新版本SP對callee這個函數作了修改增加了個參數由於caller還使用SP以前的版本所以caller還是按照個參數在傳遞而callee按照個參數在訪問所以拿到了錯誤的參數典型的DLL Hell問題在重新安裝NET Framework SP讓兩個DLL保持版本一致重新啟動後問題解決
導致DLL Hell的原因有很多根據經驗猜測版本不一致的原因可能是
安裝了NET Framework SP後沒有重新啟動導致某些正在使用的DLL必須要等到重新啟動後才能夠完成更新
由於使用了Application Center做Load Balance集群中的服務器沒有做好正確的設置導致系統自動把老版本的文件還原回去了
[] [] []
From:http://tw.wingwit.com/Article/os/xtgl/201311/10160.html
