Useless dump analysis??

WINDBG
1

I received a ‘mini’ dump from a tester today (a brief windbg session is
below), it is basically ‘unusable’ to me. Other than going back and
getting a full dump, does anyone have any tricks I can use to get some
useful info out of a mini-dump?

Thanks

Symbol search path is: SRV*downstream
store*http://msdl.microsoft.com/download/symbols;srv\*c:\cache\*http://msd
l.microsoft.com/download/symbols;V:\build_436\BuildNotes
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_rtm.040803-2158
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055ab20
Debug session time: Mon Nov 29 07:27:00 2004
System Uptime: 4 days 22:09:28.834
Loading Kernel Symbols
…
…
Loading unloaded module list
…
Loading User Symbols
************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

Use !analyze -v to get detailed debugging information.

BugCheck 100000D1, {0, ff, 0, 63006c}

Probably caused by : Unknown_Image

Followup: MachineOwner

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: 00000000, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 0063006c, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000000

CURRENT_IRQL: ff

FAULTING_IP:
+63006c
0063006c 0300 add eax,[eax]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from f44c7de0 to 0063006c

STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be
wrong.
80042000 f44c7de0 b9fc0010 00001000 760c4d89 0x63006c
838d0000 00000000 00000000 00000000 00000000 0xf44c7de0

FOLLOWUP_IP:
+63006c
0063006c 0300 add eax,[eax]

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: BAD_STACK

Followup: MachineOwner

2

I think the most useful part of this might be “LAST_CONTROL_TRANSFER: from
f44c7de0 to 0063006c”. It appears that code at f44c7de0 was probably making
a call via a function registered in a data structure, and the data structure
was overwritten by a wide character string. I don’t know how much more you
can get out of a mini dump.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Vossen, Joseph
(ISS Atlanta)
Sent: Monday, November 29, 2004 1:36 PM
To: Kernel Debugging Interest List
Subject: [windbg] Useless dump analysis??

I received a ‘mini’ dump from a tester today (a brief windbg session is
below), it is basically ‘unusable’ to me. Other than going back and
getting a full dump, does anyone have any tricks I can use to get some
useful info out of a mini-dump?

Thanks

Symbol search path is: SRV*downstream
store*http://msdl.microsoft.com/download/symbols;srv\*c:\cache\*http://msd
l.microsoft.com/download/symbols;V:\build_436\BuildNotes
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_rtm.040803-2158
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055ab20
Debug session time: Mon Nov 29 07:27:00 2004
System Uptime: 4 days 22:09:28.834
Loading Kernel Symbols
…
…
Loading unloaded module list
…
Loading User Symbols
************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

Use !analyze -v to get detailed debugging information.

BugCheck 100000D1, {0, ff, 0, 63006c}

Probably caused by : Unknown_Image

Followup: MachineOwner

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: 00000000, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 0063006c, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000000

CURRENT_IRQL: ff

FAULTING_IP:
+63006c
0063006c 0300 add eax,[eax]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from f44c7de0 to 0063006c

STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be
wrong.
80042000 f44c7de0 b9fc0010 00001000 760c4d89 0x63006c
838d0000 00000000 00000000 00000000 00000000 0xf44c7de0

FOLLOWUP_IP:
+63006c
0063006c 0300 add eax,[eax]

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: BAD_STACK

Followup: MachineOwner

You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Another possibility is the code at f44c7de0 is a return instruction and
you’ve had a buffer overrun problem writing a unicode string to a stack
location (e.g. assuming a buffer size suitable for narrow strings and
writing a wide string into it) – the 0063006c looks like it might be part
of a unicode string…

I think the minidump has the running stack in it - dump it out and look for
a unicode string…

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Croci, MaryBeth
Sent: Monday, November 29, 2004 2:20 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Useless dump analysis??

I think the most useful part of this might be “LAST_CONTROL_TRANSFER: from
f44c7de0 to 0063006c”. It appears that code at f44c7de0 was probably making
a call via a function registered in a data structure, and the data structure
was overwritten by a wide character string. I don’t know how much more you
can get out of a mini dump.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Vossen, Joseph
(ISS Atlanta)
Sent: Monday, November 29, 2004 1:36 PM
To: Kernel Debugging Interest List
Subject: [windbg] Useless dump analysis??

I received a ‘mini’ dump from a tester today (a brief windbg session is
below), it is basically ‘unusable’ to me. Other than going back and
getting a full dump, does anyone have any tricks I can use to get some
useful info out of a mini-dump?

Thanks

Symbol search path is: SRV*downstream
store*http://msdl.microsoft.com/download/symbols;srv\*c:\cache\*http://msd
l.microsoft.com/download/symbols;V:\build_436\BuildNotes
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_rtm.040803-2158
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055ab20
Debug session time: Mon Nov 29 07:27:00 2004
System Uptime: 4 days 22:09:28.834
Loading Kernel Symbols
…
…
Loading unloaded module list
…
Loading User Symbols
************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

Use !analyze -v to get detailed debugging information.

BugCheck 100000D1, {0, ff, 0, 63006c}

Probably caused by : Unknown_Image

Followup: MachineOwner

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: 00000000, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 0063006c, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000000

CURRENT_IRQL: ff

FAULTING_IP:
+63006c
0063006c 0300 add eax,[eax]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from f44c7de0 to 0063006c

STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be
wrong.
80042000 f44c7de0 b9fc0010 00001000 760c4d89 0x63006c
838d0000 00000000 00000000 00000000 00000000 0xf44c7de0

FOLLOWUP_IP:
+63006c
0063006c 0300 add eax,[eax]

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: BAD_STACK

Followup: MachineOwner

You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to windbg as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com