IT之家 4 月 24 日消息，微軟資深工程師 Raymond Chen 昨日（4 月 23 日）發(fā)布博文，披露了一起典型的 Windows 資源管理器崩潰案例，指出崩潰并非 Windows 自身缺陷導致，而是由某第三方卸載程序錯誤的函數(shù)調(diào)用約定導致內(nèi)存損壞所致。
在一次常規(guī)調(diào)試會議中，Chen 的同事發(fā)現(xiàn) Windows（原文并未明確具體版本）文件管理器崩潰率出現(xiàn)異常峰值。通過檢查崩潰轉儲文件，Chen 迅速鎖定了問題源頭：在 64 位系統(tǒng)上運行的 32 位資源管理器進程。
IT之家援引博文介紹，在 64 位 Windows 系統(tǒng)中，微軟出于兼容性考慮保留了 32 位版本的文件資源管理器，通常位于 C:/Windows/SysWOW64 目錄。
該版本一般不通過用戶直接操作觸發(fā)，主要由傳統(tǒng)的 32 位應用程序調(diào)用。Chen 據(jù)此推斷，崩潰極大概率源于某款 32 位第三方應用的非標準交互，而非用戶常規(guī)操作或系統(tǒng)內(nèi)核問題。
Chen 深入分析特定版本的故障卸載程序后，發(fā)現(xiàn)了導致崩潰的具體技術缺陷。該卸載程序的注入代碼包含一個執(zhí)行文件操作的循環(huán)，若操作失敗會暫停后重試。
然而，開發(fā)者在編寫代碼時犯下了致命錯誤：未正確指定函數(shù)調(diào)用約定。代碼錯誤地使用__cdecl 約定調(diào)用 Windows 函數(shù)，而 Windows 函數(shù)實際遵循__stdcall 約定。
這兩種約定在堆棧清理機制上存在根本差異：__stdcall 由被調(diào)用者清理堆棧參數(shù)，而__cdecl 則要求調(diào)用者清理。
這種調(diào)用約定不匹配引發(fā)了嚴重的堆棧破壞問題。每次調(diào)用 Windows 函數(shù)后，參數(shù)被壓入堆棧，Windows 函數(shù)執(zhí)行后彈出參數(shù)，隨后調(diào)用代碼再次嘗試彈出參數(shù)。這導致堆棧指針每次循環(huán)都錯誤地移動，逐步蠶食程序自身的堆?？臻g。由于重試循環(huán)執(zhí)行次數(shù)極多，堆棧最終被消耗殆盡，堆棧指針甚至遞增到了注入代碼所在的內(nèi)存區(qū)域。
這種內(nèi)存損壞導致了棧空間被“吃光”，進而直接拖垮了文件資源管理器進程?？萍济襟w NeoWin 指出，在系統(tǒng)組件出現(xiàn)崩潰后，公眾往往習慣性歸咎于操作系統(tǒng)，但第三方軟件開發(fā)者的技術失誤同樣可能成為系統(tǒng)不穩(wěn)定的根源。
相關閱讀：
廣告聲明：文內(nèi)含有的對外跳轉鏈接（包括不限于超鏈接、二維碼、口令等形式），用于傳遞更多信息，節(jié)省甄選時間，結果僅供參考，IT之家所有文章均包含本聲明。