An example of how to solve Internet Explorer crash using windbg analysis (graphic details)

Through this article, you will learn:

Lie browser crashes for several reasons

L why does the official feedback link obtained after the error report is sent fail to completely solve the crash problem?

L what is in the error report sent to Microsoft?

Advanced use of lwindbg debugging programs and related commands

L how to identify the characteristics of Dynamic Linked Library files that are actually issued by Microsoft and real files

L basic analysis ideas for solving ie crash

 

 

 

On June 23, 22nd day of this month, a friend named "120" posted a help post in the Windows client section titled "IE6 auto-disable ". In the past few days, through remote assistance and other means, with the strong cooperation of the host, the problem was finally solved. Here, we will conduct an IT show case to post the core part of the analysis and solution process into this article, providing you with a basic idea and analysis method for solving such problems, I would also like to share this article with you on this issue.

 

When it comes to the crash of IE, it may be a common occurrence, which is strange. In this case, the host description is that when some websites are opened, ie automatically closes and requires an error report. The host environment is Microsoft Windows XP Pro with SP2, and the error module is urlmon. dll. Based on experience, this is not the culprit of the crash, so I need to analyze the crash of the host. The following is the crash:

 

 

 

Although Microsoft has been improving its stability in the release of IE, even the new IE6, IE7, and IE8 that are still in the beta2 test phase, will still be unstable, or suspension, or crash, but it is slightly more stable than the previous version. Careful friends may find that if your windows has enabled program error reporting, you will be asked to send an error report to Microsoft after IE crashes, sometimes, a link for solving the problem will be reported immediately. After you click it, you will go to the Microsoft online Crash Analysis page, some solutions such as installing the latest patch, using anti-virus software, and disabling third-party add-ons are provided. However, some users still cannot solve the problem after these operations. Why?

In fact, the crash of IE is nothing more than the following situations, it loads unstable plug-ins, exploits vulnerabilities, becomes unstable, lacks files, is hijacked by rogue software, and contains Trojans or viruses. Microsoft's feedback link should be the most effective for the first three cases, but it is often powerless for the following complicated and changing situations. One important reason is that sometimes the files that actually cause the crash are not included in the error report sent to Microsoft. That is to say, when Microsoft analyzes the report, I cannot realize that IE has loaded such a problematic component. In the middle (to http://bbs.winos.cn/viewthread.php? Tid = 50046 download). If you are interested, you can open it and find the DLL.

 

If we use the windbg append to the process for debugging, We can get ie loaded this DLL, due to limited space, the following only shows one of the fragments: (the progress of the analysis information in the attachment processanalysis.rar, go to the http://bbs.winos.cn/viewthread.php? Download tid = 50046)

 

Code:

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

 

 

Because Remote Assistance is affected by the speed of the network and cannot be analyzed more, I used ". dump/Ma IE. the DMP command generates a minidump memory dump file of the currently crashed IE, and the host sends it to me through the network for further analysis.

After obtaining ie. DMP, use windbg for loading. Use "! The analyze-V command is used for analysis. windbg obtains the faultrep. dll module that automatically identifies the cause. The following are related fragments:

 

Code:

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

 

 

Is it true? Run the "lmvm faultrep" command to obtain the following results:

 

 

Code:

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.

 

 

Obviously, this DLL is one of the core components of the Windows Error Report and is not the culprit of the problem. Therefore, for windbg analysis, we still need to think about the root cause of the problem. The next step is to find out the culprit of the problem. Use the "kb" command to display the thread stack information. The command result is as follows:

 

 

Code:

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

 

 

Please note the part after warning! At the same time, we provide the following key parts:

 

 

 

Clearly, the function here is the key to the problem. The function is provided by msxmlfilta. dll. Looking back at the entire analysis process, we found that windbg was always unable to load the symbol (symbols) for it, so this should not be a Microsoft File. (See the appendix dumpanalysis.rar for my minidumpanalysis results, go to http://bbs.winos.cn/viewthread.php? Tid = 50046 download) We need to check that its properties are confirmed. I got a sample of this file through the Internet. Some netizens said it was from the deamon tools virtual optical drive and confirmed on the host that he indeed installed the virtual optical drive. However, when viewing the attributes, I found that the attributes of this file are counterfeited. Below is a comparison between this file and a Microsoft release component on the right:

 

 

 

We know that all components officially released by Microsoft have descriptions, and the description of this file is mshttpapp. DLL is not normal, and the version number in Microsoft's component version information should be the same as that in Windows or the version number of Microsoft's software (such as IE). 5.1.2600 is the XP version number, which Windows system component is 1.0.0.1? Moreover, Rising antivirus software reports it as a risk-advertising program,

 

 

 

After the test, not all antivirus software reports the file, so the host's antivirus software does not report it. But how does this file cause IE to crash? We use exists for function and associated analysis, such:

 

 

 

Obviously, this file provides four function functions, most of which are related to DLL registration/anti-Registration, loading/uninstallation. In addition, we find in the left column that it is exported as an mshttpapp. dll, that is, it can be called and the result is passed to mshttpapp. dll. The problem lies here. The host confirms that there is no such mshttpapp. dll on his computer. So we can delete msxmlfilta. dll from unknown sources to solve the problem. (In this example, msxmlfilta. dll is not registered and can be deleted directly. In case of registration or occupation, use the "regsvr32/u msxmlfilta. dll" command for reverse registration and then delete it)

 

 

Here, the problem is solved. But I still have a few questions. Does msxmlfilta. dll really come from deamon tools virtual optical drive? Is it a component of it? Why is it counterfeit? Why is it reported by some anti-virus software? What functions does it use to execute? Due to the recent busy schedule and limited time, we only need to wait until the environment is established for further analysis. This requires analysis of the complete installation and use process of deamon tools. If you already have this experience or know the relevant information, please let me know here and we will discuss it together.