Debug 101: What does !analyze do?

Over the last few weeks, we’ve been posting quite a bit on different topics related to Debugging. Today we’re continuing in that vein by looking at one of the most common commands that we use when reviewing both kernel- and user-mode dump files – !analyze. !analyze is an extension command that performs a number of automated analysis steps and displays information about the exception or bug check in the dump file. There are a couple of different parameters that you can use, depending on whether or not you are debugging a kernel- or user-mode dump file, but the one that you will probably use most often is –v which shows the verbose output. As with our other posts on debugging commands, let’s go through the parameters first, and then take a look at some examples:

Parameter	Information
-v	Displays verbose output
-f	Generates the !analyze exception output. Use this to see an exception analysis even when the debugger doesn’t detect an exception
-hang	Generates hung-application output – use this in the event that you are analyzing a bug check or exception dump but analyzing why an application hung is more relevant. If you run this command on a kernel-mode dump, the command investigates locks that the system holds, and scans the DPC queue chain. In a user-mode dump, it analyzes the thread stack to determine if there are any blocking threads. In user-mode, you may have to change the thread from the current one to the one that you think is hung – the exception may have switched the current thread to a different one
-show BugCheckCode [BugParameters]	Shows information about the bug check code. The BugCheckCode specifies which code to display. The BugParameters value (you can specify up to four) allows you to refine your search. Separate the parameters with spaces.

OK – now let’s take a look at some examples of !analyze in action beginning with the straightforward command. The dump file I’m using for this post is from a Windows XP SP3 system using an in-house debug training application to create the bugcheck.

1: kd> !analyze
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {e5a30000, 2, 1, ba636729}

Probably caused by : buggy.sys ( buggy+729 )

Followup: MachineOwner

As you can see there is very little information here – just the parameters for the bugcheck and a probable cause. Now let’s look at the output from the !analyze –v command:

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
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: e5a30000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: ba636729, address which referenced memory

Debugging Details:
------------------

WRITE_ADDRESS:  e5a30000 Paged pool

CURRENT_IRQL:  2

FAULTING_IP: 
buggy+729
ba636729 f3ab            rep stos dword ptr es:[edi]

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  dbgt.exe

TRAP_FRAME:  ae5e6bb8 -- (.trap 0xffffffffae5e6bb8)
.trap 0xffffffffae5e6bb8
ErrCode = 00000002
eax=00000000 ebx=88e03348 ecx=00002800 edx=00000000 esi=88e03348 edi=e5a30000
eip=ba636729 esp=ae5e6c2c ebp=ae5e6c34 iopl=0         nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
buggy+0x729:
ba636729 f3ab            rep stos dword ptr es:[edi]
.trap
Resetting default scope

LAST_CONTROL_TRANSFER:  from ba636729 to 805446f0

STACK_TEXT:  
ae5e6bb8 ba636729 badb0d00 00000000 00000000 nt!KiTrap0E+0x238
WARNING: Stack unwind information not available. Following frames may be wrong.
ae5e6c34 ba636894 88ef8280 88f73808 804ef19f buggy+0x729
ae5e6c64 805807f7 88fc0d38 88e03348 88ef8280 buggy+0x894
ae5e6d00 80579274 000002ec 00000000 00000000 nt!IopXxxControlFile+0x5c5
ae5e6d34 8054162c 000002ec 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
ae5e6d34 7c90e514 000002ec 00000000 00000000 nt!KiFastCallEntry+0xfc
0012f6c0 7c90d28a 7c801675 000002ec 00000000 ntdll!KiFastSystemCallRet
0012f6c4 7c801675 000002ec 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
0012f724 00414bac 000002ec 00220014 00000000 kernel32!DeviceIoControl+0xdd
0012f830 0041565d 00040222 00220014 0012fa9c dbgt+0x14bac
0012f90c 00413d2d 0000012d 00220014 00040222 dbgt+0x1565d
0012fa9c 7e418734 00040222 00000111 000003ec dbgt+0x13d2d
0012fac8 7e418816 004115b9 00040222 00000111 USER32!InternalCallWinProc+0x28
0012fb30 7e42927b 00000000 004115b9 00040222 USER32!UserCallWinProcCheckWow+0x150
0012fb6c 7e4292e3 0075f640 0075f5c0 000003ec USER32!SendMessageWorker+0x4a5
0012fb8c 7e44ff7d 00040222 00000111 000003ec USER32!SendMessageW+0x7f
0012fba4 7e4465d2 00761248 00000000 00761248 USER32!xxxButtonNotifyParent+0x41
0012fbc0 7e425e94 001c4d40 00000001 00000000 USER32!xxxBNReleaseCapture+0xf8
0012fc44 7e425231 00761248 00000202 00000000 USER32!ButtonWndProcWorker+0x6df
0012fc64 7e418734 00010414 00000202 00000000 USER32!ButtonWndProcW+0x4c
0012fc90 7e418816 7e4251d1 00010414 00000202 USER32!InternalCallWinProc+0x28
0012fcf8 7e4189cd 00000000 7e4251d1 00010414 USER32!UserCallWinProcCheckWow+0x150
0012fd58 7e418a10 0012fe68 00000000 0012fe88 USER32!DispatchMessageWorker+0x306
0012fd68 0041219e 0012fe68 80000001 02e2d9e4 USER32!DispatchMessageW+0xf
0012fe88 00416760 00400000 00000000 0002072a dbgt+0x1219e
0012ffc0 7c817077 80000001 02e2d9e4 7ffd5000 dbgt+0x16760
0012fff0 00000000 00411758 00000000 78746341 kernel32!BaseProcessStart+0x23


STACK_COMMAND:  kb

FOLLOWUP_IP: 
buggy+729
ba636729 f3ab            rep stos dword ptr es:[edi]

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  buggy+729

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: buggy

IMAGE_NAME:  buggy.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  40a88083

FAILURE_BUCKET_ID:  0xD1_buggy+729

BUCKET_ID:  0xD1_buggy+729

Followup: MachineOwner

Wow – lots more information for us including the stop code information, the stack and the current IRQL. If I just wanted to review the information on the error itself using the –show parameter, here’s what I would get back:

1: kd> !analyze -show D1 e5a30000 2 1 ba636729
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
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: e5a30000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: ba636729, address which referenced memory

Now, we’re not going to get into the actual debugging of this crash, but those of you who have some experience with bugchecks and debugging have probably already spotted the cause for this bugcheck just from the data given. The resources provided below go into more detail on some of the other pieces of data in the verbose output. That’s all for today folks – have a great Tuesday! Until next time …

Additional Resources:

- CC Hameed

Share this post :