分析解決Internet Explorer崩潰一例
?
本文為Eric原創技術文章，如需轉載請事先與我取得聯系。首發于WinOS.cn，僅限站內交流分享。
?
通過本文，您將了解到：
??l
IE
瀏覽器產生崩潰的幾類原因
??l
為什么發送錯誤匯報之后得到的官方反饋鏈接不能夠幫助徹底解決崩潰問題
??l
發送給微軟的錯誤匯報里面都是什么內容
??l
WinDbg
調試程序的進階使用以及相關命令
??l
如何鑒別動態鏈接庫文件是否真正為微軟公司發行以及真文件的幾點特征
??l
解決IE崩潰的基本分析思路
?
? ? 本月22日，一個名叫“120”的朋友在Windows Client板塊發表了一個求助帖，標題為“IE6自動關閉”。這幾天，通過遠程協助等手段，在機主的極力配合之下，問題終于得以解決。在這里，我們進行一個IT Show Case，將整理過后的分析解決過程的核心部分發表成此文，為大家提供一個解決此類問題的基本思路及分析方法，也借此文在這里與大家進行一個關于此問題的交流。
? ? 說到IE的崩潰，也許那簡直就是家常便飯，見怪不怪了。本案例中，機主的描述也是打開一些網站的時候，IE自動關閉而且要求錯誤報告，機主的環境是Microsoft Windows XP Pro with SP2，錯誤模塊為Urlmon.dll。根據經驗，這并不是引起崩潰的元兇，那么我需要對機主的崩潰進行一個具體的分析。下面就是這個崩潰的截圖：
?
?
? ? 雖然微軟公司在IE的發行中一直在改善其穩定性，但是就算較新的IE6、IE7甚至于目前還在Beta2測試階段的IE8都仍然會出現不穩定現象，或掛起、或崩潰，只是相對于以前的版本要稍稍穩定一些了。細心的朋友可能發現，如果您的Windows啟用了程序錯誤匯報，那么IE崩潰之后會要求您發送一個錯誤報告給微軟，有的時候還會立即反饋一個用于解決問題的鏈接，點擊之后將前往微軟聯機崩潰分析頁面，提供一些安裝最新補丁、使用防病毒軟件、禁用第三方加載項之類的解決方案，而往往有的用戶進行這些操作之后卻仍不能夠解決問題，是什么原因呢？
? ? 其實，IE的崩潰無非有這樣幾類情況，即加載了不穩定的插件、有漏洞被利用、自身不穩定、缺少文件、被流氓軟件劫持、存有木馬或者病毒。微軟的反饋鏈接應該來說對于前三種情況是最有效的，而對于后面的幾種較為復雜多變的情況，往往是無能為力的。其中有一個重要原因——有的時候真正引起崩潰的文件并沒有包含在發送給微軟的錯誤報告中，也就是說，微軟分析的時候，根本意識不到IE加載了這樣的一個問題組件。關于這一點，本例就是一個很好的證明，本例中真正引起崩潰的是msxmlfilta.dll，我將發送給微軟的錯誤匯報技術信息附在本文的附件errorperort_to_Microsoft.rar之中（前往http://bbs.winos.cn/viewthread.php?tid=50046下載），有興趣的朋友可以打開來查找一下這個DLL，可以發現是查找不到的。
? ? 如果我們使用WinDbg的附加到進程進行調試的功能，可以得到IE加載了這個DLL，由于篇幅有限，下面僅展示其中的一個片段：（完整的進程分析信息位于附件的ProcessAnalysis.rar，前往http://bbs.winos.cn/viewthread.php?tid=50046下載）
?
代碼:
ModLoad: 77bb0000 77bc5000? ?C:\WINDOWS\system32\MSACM32.dll
ModLoad: 77ba0000 77ba7000? ?C:\WINDOWS\system32\midimap.dll
ModLoad: 038f0000 0391a000? ?C:\WINDOWS\system32\msxmlfilta.dll
ModLoad: 69760000 69776000? ?C:\WINDOWS\system32\faultrep.dll
ModLoad: 76f20000 76f28000? ?C:\WINDOWS\system32\WTSAPI32.dll
(334.cb0): Break instruction exception - code 80000003 (first chance)
eax=7ffde000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004 edi=00000005
eip=7c921230 esp=0396ffcc ebp=0396fff4 iopl=0? ?? ?? ?nv up ei pl zr na pe nc
cs=001b??ss=0023??ds=0023??es=0023??fs=0038??gs=0000? ?? ?? ?? ? efl=00000246
ntdll!DbgBreakPoint:
7c921230 cc? ?? ?? ?? ???int? ???3
?
? ? 由于遠程協助受到網絡速度的影響，不能夠進行更多地分析，于是我使用了“.dump /ma IE.DMP”命令生成了一個當前崩潰IE的Minidump內存轉儲文件，然后機主通過網絡發送給我做進一步分析。
? ? 得到IE.DMP之后，使用WinDbg進行加載。使用“!Analyze -v”命令進行分析，WinDbg得到了自動判別出的一個引起問題的模塊——faultrep.dll。下面是相關的片段：
代碼:
PRIMARY_PROBLEM_CLASS:??STATUS_BREAKPOINT
BUGCHECK_STR:??APPLICATION_FAULT_STATUS_BREAKPOINT
MODULE_NAME: faultrep
STACK_COMMAND:??~0s ; kb
FAILURE_BUCKET_ID:??APPLICATION_FAULT_STATUS_BREAKPOINT_faultrep!StartDWException+5df
BUCKET_ID:??APPLICATION_FAULT_STATUS_BREAKPOINT_faultrep!StartDWException+5df
Followup: MachineOwner
?
? ? 真的是它么？使用“lmvm faultrep”命令，得到以下結果：
?
代碼:
start? ? end? ?? ???module name
69760000 69776000? ?faultrep? ?(pdb symbols)? ?? ?? ? DownstreamStore\faultrep.pdb\3894E0C34E6A43099670AE3EB5AFD94D1\faultrep.pdb
? ? Loaded symbol image file: faultrep.dll
? ? Image path: C:\WINDOWS\system32\faultrep.dll
? ? Image name: faultrep.dll
? ? Timestamp:? ?? ???Tue Aug 17 07:37:33 2004 (4121453D)
? ? CheckSum:? ?? ?? ?0001F72E
? ? ImageSize:? ?? ???00016000
? ? File version:? ???5.1.2600.2180
? ? Product version:??5.1.2600.2180
? ? File flags:? ?? ? 0 (Mask 3F)
? ? File OS:? ?? ?? ? 40004 NT Win32
? ? File type:? ?? ???1.0 App
? ? File date:? ?? ???00000000.00000000
? ? Translations:? ???0804.04b0
? ? CompanyName:? ?? ?Microsoft Corporation
? ? ProductName:? ?? ?Microsoft(R) Windows (R) 2000 Operating System
? ? InternalName:? ???FAULTREP.DLL
? ? OriginalFilename: FAULTREP.DLL
? ? ProductVersion:? ?5.1.2600.2180
? ? FileVersion:? ?? ?5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
? ? FileDescription:??Windows Error Reporting
LegalCopyright:? ?(C) Microsoft Corporation. All rights reserved.
?
? ? 很明顯，這個DLL是Windows錯誤報告的核心組件之一，并不是引起問題的元兇。所以對于WinDbg的分析，我們還需要加以思考才能判別出問題的根源。那么下一步就是要查明問題的元兇了。使用“kb”命令顯示線程堆棧信息。下面是命令結果：
?
代碼:
ChildEBP RetAddr??Args to Child? ?? ?? ?? ???
0013aa64 7c92e9ab 7c8094e2 00000002 0013aa90 ntdll!KiFastSystemCallRet
0013aa68 7c8094e2 00000002 0013aa90 00000001 ntdll!ZwWaitForMultipleObjects+0xc
0013ab04 7c80a075 00000002 0013ac34 00000000 kernel32!WaitForMultipleObjectsEx+0x12c
0013ab20 6976763c 00000002 0013ac34 00000000 kernel32!WaitForMultipleObjects+0x18
0013b4b4 697682b1 0013cbf0 ffffffff 00198312 faultrep!StartDWException+0x5df
0013c528 7c8633b1 0013cbf0 ffffffff 0013ee48 faultrep!ReportFault+0x533
0013cbc8 75f1ea3f 0013cbf0 77c05cf5 0013cbf8 kernel32!UnhandledExceptionFilter+0x587
0013cbd0 77c05cf5 0013cbf8 00000000 0013cbf8 browseui!BrowserProtectedThreadProc+0x65
0013cbf8 7c9237bf 0013cce4 0013ee5c 0013cd00 msvcrt!_except_handler3+0x61
0013cc1c 7c92378b 0013cce4 0013ee5c 0013cd00 ntdll!ExecuteHandler2+0x26
0013cccc 7c92eafa 00000000 0013cd00 0013cce4 ntdll!ExecuteHandler+0x24
0013cccc 75c71ed3 00000000 0013cd00 0013cce4 ntdll!KiUserExceptionDispatcher+0xe
0013cfd4 75c73099 001d3818 00237d3c 00237d40 urlmon!CTransaction::GetBindInfo+0x10
0013cffc 011b68d7 00237c00 0013d054 017c8dc0 urlmon!CINet::Start+0x5f
WARNING: Stack unwind information not available. Following frames may be wrong.
0013d034 011b675b 0013d054 001d3810 017c8dc0 msxmlfilta!DllUnregisterServer+0x1a27
0013d104 011b64e4 011b64f5 00000000 017c8d8c msxmlfilta!DllUnregisterServer+0x18ab
0013d108 011b64f5 00000000 017c8d8c 001d3824 msxmlfilta!DllUnregisterServer+0x1634
0013d130 7c9306eb 017c4b00 00150000 00000000 msxmlfilta!DllUnregisterServer+0x1645
001ad858 772f2f3a 622e7777 75646961 6d6f632e ntdll!RtlAllocateHeap+0xeac
001ad858 00000000 622e7777 75646961 6d6f632e 0x772f2f3a
?
? ? 請注意到字樣WARNING后面的部分！同時我們給出這個關鍵部分的截圖：
?
?
? ? 從圖中清晰地可以看到，這里的函數才是問題的關鍵，函數是msxmlfilta.dll提供的。回顧整個分析過程，發現WinDbg始終無法為它加載符號（Symbols），因此這個應該不是微軟的文件吧。（完整的Minidump分析結果見附件DumpAnalysis.rar，前往http://bbs.winos.cn/viewthread.php?tid=50046下載）我們需要察看它的屬性得到證實。我通過互聯網得到了這個文件的一個樣本，有的網友說它是來自于Deamon Tools虛擬光驅的，而且在機主那兒得到證實，他的確安裝了這個虛擬光驅。但是，查看屬性時我發現，這個文件的屬性具有仿冒特征，下面是它與右邊的一個微軟發行組件的對比：
?
?
? ? 我們知道，微軟官方發行的組件都有描述，而這個文件的描述MsHttpApp.dll也未免不正常吧，再有就是微軟的組件版本信息中版本號應該與Windows一致，或者與其軟件（如IE）的版本號一致才對，5.1.2600為XP的版本號，現在哪一個Windows的系統組件還是1.0.0.1呢？而且瑞星殺毒軟件報告它為風險-廣告程序，如圖：
?
?
? ? 通過測試，并不是所有的殺毒軟件均報告該文件，因此機主的殺毒軟件并沒有報告它。但是這個文件又是如何造成IE崩潰的呢？我們使用exeScope進行函數以及關聯的分析，如下圖：
?
?
? ? 很明顯，這個文件就提供四個函數功能，大多都是與DLL注冊/反注冊、加載/卸載有關的。而且在左欄我們發現，它的導出為一個MsHttpApp.dll，也就是說它可以供其調用，將結果傳遞給MsHttpApp.dll。問題就在這里了，機主證實他的計算機上并沒有存在這樣一個MsHttpApp.DLL。于是我們將這個來歷不明的msxmlfilta.DLL刪除即可解決問題。（本例中msxmlfilta.DLL并沒有被注冊占用，因此可以直接刪除。萬一被注冊占用，請使用“regsvr32 /u msxmlfilta.DLL”命令進行反注冊，然后再刪除即可）
?
? ? 到這里，問題就解決了。但是我仍存有幾個疑問。這個msxmlfilta.DLL真的來源于Deamon Tools虛擬光驅嗎？是它的一個組件嗎？為什么具有仿冒特征？為什么被部分反病毒軟件報告？它究竟是用來執行什么功能的？由于最近比較忙，時間有限，因此只有等到日后再架設環境進行進一步分析了，這需要分析Deamon Tools的完整安裝和使用過程。如果您已經有此方面的經歷或者知道相關的信息，也請在此告訴我，我們一同來探討。
? ? 謝謝大家！