用WinDbg分析解決Internet Explorer崩潰一例(圖文詳解)

通過本文，您將瞭解到：

  lIE瀏覽器產生崩潰的幾類原因

  l為什麼發送錯誤彙報之後得到的官方反饋連結不能夠協助徹底解決崩潰問題

  l發送給微軟的錯誤彙報裡面都是什麼內容

  lWinDbg偵錯工具的進階使用以及相關命令

  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的完整安裝和使用過程。如果您已經有此方面的經曆或者知道相關的資訊，也請在此告訴我，我們一同來探討。