First glance-windbg analysis dump

Dump File analysis is largely the cause of blue screen analysis. This kind of system-level error is one of the most serious Windows Prompt errors (more serious are hardware or software compatibility errors such as black screen startup ). It is serious because, after all, windows also provides the dump file for user analysis, at least it is easier to find the cause of the error. Generally, the blue screen is either abnormal or illegal in the kernel program, damaged data structure, or kernel error during boot or shutdown. Sometimes the blue screen is a flash, followed by a system restart; sometimes the blue screen is waiting. In short, some stop code and error messages are prompted during the blue screen, but these prompts are not comprehensive, and you can know which module has an error (such as a driver) at most ). For more information, or search engines, the best method is dump file analysis. Of course, kernel debugging is a better method if you want to study it further, but it requires some software support and debugging skills.

Type
There are three types of dump files: full memory dump, kernel memory dump, and small memory dump. You can see these settings in the advanced options in system properties.
The complete memory dump is too large, generally the physical memory size or more, including the user process page. This method is not practical, 2 GB of physical memory is dumped to at least 2 GB of disk space (with file header information ). The size of the core dump is generally MB (the physical memory is smaller than 4 GB). It only contains all the physical memory in kernel mode. A small memory dump is usually 64 KB (kb in 64-Bit mode). These two methods are more commonly used.
A mini date + serial number is generated under/Windows/minidump in the small memory dump. DMP files, this precious resource is the state of the system crash moment, but a small memory dump only records limited information, and when you analyze, if the path of the symbol server is not set for windbg (for the symbol server, refer to windbg kernel debugging 2: common command line, so your current system version is the same as the ntoskrnl.exe version of the blue screen system, otherwise there will be issues with the symbol not found.
Start windbg, use open crash dump to open the dump file, or drag the file to windbg. windbg displays the following information:
Loading dump files [C:/dbg/Mini052809-01.dmp]
Mini kernel dump file: only registers and stack trace are available
Symbol search path is: SRV * D:/temp/* http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Vista kernel version 6000 (Service Pack 1) Up Free x86 compatible
Kernel base = 0x80400000 psloadedmodulelist = 0x8046e8f0
Debug session time: Thu May 28 16:12:29. 031 2009 (GMT + 8)
System uptime: not available
Loading kernel symbols ..................................... ..........................
Loading unloaded module list .................................... .................................

Loading usersymbols
**************************************** **************************************** ** Bugcheck analysis ************************************ **************************************** ******
Use! Analyze-V to get detailed debugging information.
Bugcheck 7f, {0, 0, 0, 0}

In general, the version of the crash system is prompted. If the symbolic file cannot be found, the system prompts "unable to load image. If the following error is returned, the ntoskrnl.exe symbolic file cannot be found:

Unable to load image/SYSTEMROOT/system32/ntoskrnl.exe, Win32 error 0n2
* ** Warning: unable to verify timestamp for ntoskrnl.exe
* ** Error: module Load completed but symbols cocould not be loaded for ntoskrnl.exe

Command
Run the LM command to view the module list.In addition, if the file unable to load image is found, check whether the correct symbol file is loaded. It is necessary to set the symbolic server path (. symfix command) because the debugging machine and the crash machine may be in different environments.
Run the command kb to display the call stack information. If you have the correct symbol settings, you can see the name of the called function. If you are debugging the blue screen of your own driver, make sure to set the correct path of the driver. Otherwise, the stack unwind information not available problem may occur. After adding the correct symbol file (PDB), you can use the command! Reload: Reload the symbol file.
Pass! Thread and! Process to display the current process and thread. Or through DT nt! _ Kthread address and DT nt! _ Eprocess address to view the thread and process structure.

Windbg provides a mechanism for Automatic Analysis of dump files. Run the command! Analyze-V and windbg can automatically perform analysis and display the following information:
**************************************** ***************************************
**
* Bugcheck analysis *
**
**************************************** ***************************************

Driver_irql_not_less_or_equal (D1)
An attempt was made to access a pageable (or completely invalid) address at
Interrupt request level (IRQL) that is too high. This is usually
Caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: e1147008, memory referenced
Arg2: 10000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: fbe93403, address which referenced memory

Debugging details:
------------------
Read_address: e1147008 paged pool
Current_irql: 1c
Faulting_ip:
Myfailure + 403
Fbe93403 8b06 mov eax, dword ptr [esi]

Default_bucket_id: driver_fault
Bugcheck_str: 0xd1
Process_name: notmyfault.exe

Trap_frame: f9357b80 -- (trap fffffffff9357b80)
Errcode = 00000000
Eax = 00000000 EBX = 8111f330 ECx = 000000d1 edX = 0000001c ESI = e1147008 EDI = 00000000
EIP = fbe93403 ESP = f9357bf4 EBP = f9357c58 iopl = 0 NV up ei pl Zr na PE NC
Cs = 0008 Ss = 0010 DS = 0023 es = 0023 FS = 0030 GS = 0000 EFL = 00010246
Myfault + 0x403:
Fbe93403 8b06 mov eax, dword ptr [esi] DS: 0023: e1147008 == ????????
Resetting default Scope

Last_control_transfer: From 804f880d to 80527da8

Stack_text:
F9357734 804f880d 00000003 f9357a90 00000000 nt! Rtlpbreakwithstatusinstruction
F9357780 804f93fa 00000003 e1147008 fbe93403 nt! Kibugcheckdebugbreak + 0x19
F9357b60 80540853 0000000a e1147008 0000001c nt! Kebugcheck2 + 0x574
F9357b60 fbe93403 0000000a e1147008 0000001c nt! Kitrap0e + 0x233
Warning: Stack unwind Information not available. Following frames may be wrong.
F9357c58 805759d1 ffb5c3b0 8111f318 811d9130 myfault + 0x403
F9357d00 8056e33c 00000090 00000000 00000000 nt! Iopxxxcontrolfile + 0x5e7
F9357d34 8053d808 00000090 00000000 00000000 nt! Ntdeviceiocontrolfile + 0x2a
F9357d34 7c92eb94 00000090 00000000 00000000 nt! Kifastcallentry + 0xf8
0012f9f0 7c92d8ef 7c801671 00000090 00000000 NTDLL! Kifastsystemcallret
0012f9f4 7c801671 00000090 00000000 00000000 NTDLL! Zwdeviceiocontrolfile + 0xc
0012fa54 004018c2 00000090 83360018 00000000 0x7c801671

Stack_command: KB

Followup_ip:
Myfailure + 403
Fbe93403 8b06 mov eax, dword ptr [esi]

Symbol_stack_index: 4
Followup_name: machineowner
Module_name: myfault
Image_name: myfault. sys
Debug_flr_image_timestamp: 43774e1d
Symbol_name: myfault + 403
Failure_bucket_id: 0xdw.myfault + 403
Bucket_id: 0xdw.myfault + 403
Followup: machineowner

Generally, follow the following steps: Stop code explanation, trap frame register information, blue screen attributes (some errors are displayed here), stack call, wrong command location (followup_ip ), error source code and assembly code lines, error code lines, error module information (including owner and other information) to organize automatic analysis information.

The R command can be used to display the status of the crash time register and the final command status.

Run the D command to display the current memory address. After locating the error code line, you can further perform kernel debugging and system debugging.

 

From: http://www.horseb.net/html/6155/6155.html