【天天报资讯】如何解决lIE浏览器的崩溃？lWin浏览器产生崩溃的几类原因

通过本文，您将了解到：

(资料图)

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之中，有兴趣的朋友可以打开来查找一下这个DLL，可以发现是查找不到的。

如果我们使用WinDbg的附加到进程进行调试的功能，可以得到IE加载了这个DLL，由于篇幅有限，下面仅展示其中的一个片段：（完整的进程分析信息位于附件的ProcessAnalysis.rar）

ModLoad: 77bb0000 77bc5000   C:/WINDOWS/system32/MSACM32.dllModLoad: 77ba0000 77ba7000   C:/WINDOWS/system32/midimap.dllModLoad: 038f0000 0391a000   C:/WINDOWS/system32/msxmlfilta.dllModLoad: 69760000 69776000   C:/WINDOWS/system32/faultrep.dllModLoad: 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=00000005eip=7c921230 esp=0396ffcc ebp=0396fff4 iopl=0         nv up ei pl zr na pe nccs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00000246ntdll!DbgBreakPoint:7c921230 cc              int     3 复制代码

由于远程协助受到网络速度的影响，不能够进行更多地分析，于是我使用了“.dump /ma IE.DMP”命令生成了一个当前崩溃IE的Minidump内存转储文件，然后机主通过网络发送给我做进一步分析。

得到IE.DMP之后，使用WinDbg进行加载。使用“!Analyze -v”命令进行分析，WinDbg得到了自动判别出的一个引起问题的模块——faultrep.dll。下面是相关的片段：

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINTBUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINTMODULE_NAME: faultrepSTACK_COMMAND:  ~0s ; kbFAILURE_BUCKET_ID:  APPLICATION_FAULT_STATUS_BREAKPOINT_faultrep!StartDWException+5dfBUCKET_ID:  APPLICATION_FAULT_STATUS_BREAKPOINT_faultrep!StartDWException+5dfFollowup: MachineOwner 复制代码

真的是它么？使用“lmvm faultrep”命令，得到以下结果：

start    end        module name69760000 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 ReportingLegalCopyright:   (C) Microsoft Corporation. All rights reserved. 复制代码

很明显，这个DLL是Windows错误报告的核心组件之一，并不是引起问题的元凶。所以对于WinDbg的分析，我们还需要加以思考才能判别出问题的根源。那么下一步就是要查明问题的元凶了。使用“kb”命令显示线程堆栈信息。下面是命令结果：

ChildEBP RetAddr  Args to Child              0013aa64 7c92e9ab 7c8094e2 00000002 0013aa90 ntdll!KiFastSystemCallRet0013aa68 7c8094e2 00000002 0013aa90 00000001 ntdll!ZwWaitForMultipleObjects+0xc0013ab04 7c80a075 00000002 0013ac34 00000000 kernel32!WaitForMultipleObjectsEx+0x12c0013ab20 6976763c 00000002 0013ac34 00000000 kernel32!WaitForMultipleObjects+0x180013b4b4 697682b1 0013cbf0 ffffffff 00198312 faultrep!StartDWException+0x5df0013c528 7c8633b1 0013cbf0 ffffffff 0013ee48 faultrep!ReportFault+0x5330013cbc8 75f1ea3f 0013cbf0 77c05cf5 0013cbf8 kernel32!UnhandledExceptionFilter+0x5870013cbd0 77c05cf5 0013cbf8 00000000 0013cbf8 browseui!BrowserProtectedThreadProc+0x650013cbf8 7c9237bf 0013cce4 0013ee5c 0013cd00 msvcrt!_except_handler3+0x610013cc1c 7c92378b 0013cce4 0013ee5c 0013cd00 ntdll!ExecuteHandler2+0x260013cccc 7c92eafa 00000000 0013cd00 0013cce4 ntdll!ExecuteHandler+0x240013cccc 75c71ed3 00000000 0013cd00 0013cce4 ntdll!KiUserExceptionDispatcher+0xe0013cfd4 75c73099 001d3818 00237d3c 00237d40 urlmon!CTransaction::GetBindInfo+0x100013cffc 011b68d7 00237c00 0013d054 017c8dc0 urlmon!CINet::Start+0x5fWARNING: Stack unwind information not available. Following frames may be wrong.0013d034 011b675b 0013d054 001d3810 017c8dc0 msxmlfilta!DllUnregisterServer+0x1a270013d104 011b64e4 011b64f5 00000000 017c8d8c msxmlfilta!DllUnregisterServer+0x18ab0013d108 011b64f5 00000000 017c8d8c 001d3824 msxmlfilta!DllUnregisterServer+0x16340013d130 7c9306eb 017c4b00 00150000 00000000 msxmlfilta!DllUnregisterServer+0x1645001ad858 772f2f3a 622e7777 75646961 6d6f632e ntdll!RtlAllocateHeap+0xeac001ad858 00000000 622e7777 75646961 6d6f632e 0x772f2f3a 复制代码

请注意到红色字样WARNING后面的部分！同时我们给出这个关键部分的截图：

从图中清晰地可以看到，这里的函数才是问题的关键，函数是msxmlfilta.dll提供的。回顾整个分析过程，发现WinDbg始终无法为它加载符号（Symbols），因此这个应该不是微软的文件吧。（完整的Minidump分析结果见附件DumpAnalysis.rar）我们需要察看它的属性得到证实。我通过互联网得到了这个文件的一个样本，有的网友说它是来自于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的完整安装和使用过程。如果您已经有此方面的经历或者知道相关的信息，也请在此告诉我，我们一同来探讨。谢谢大家！