Crash Dump analysis ...

NTDEV
1

Hi Gurus,

I have a crash dump to analyze… the question I have is …

  1. If I look at the stack trace, I don’t see my driver listed. I am not
    sure if the problem was caused by my driver, or is actually a bug in
    tcpip.sys (which i doubt). So, how can I figure that out ? I don’t have
    much experience with looking at crash dumps, and was looking at
    pointers, suggestions, to proceed with this …

Any help, pointers is appreciated.

Thanks,
-g

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

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pagable (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: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: bfe3306a, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000000

CURRENT_IRQL: 2

FAULTING_IP:
tcpip!TCPSendComplete+61
bfe3306a 8b3f mov edi,[edi]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

TRAP_FRAME: 80473df0 – (.trap ffffffff80473df0)
ErrCode = 00000000
eax=00000000 ebx=00000002 ecx=adfb00bb edx=adfa00ba esi=816ae8c0
edi=00000000
eip=bfe3306a esp=80473e64 ebp=80473e74 iopl=0 nv up ei ng nz ac
pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010293
tcpip!TCPSendComplete+61:
bfe3306a 8b3f mov edi,[edi]
ds:0023:00000000=???
Resetting default context

LAST_CONTROL_TRANSFER: from bfe32682 to bfe3306a

STACK_TEXT:
80473e74 bfe32682 816ae8c0 816af688 00000000 tcpip!TCPSendComplete+0x61
80473eac bfe32536 81fa97c8 00000000 00000000 tcpip!IPSendComplete+0x13c
80473ecc bff87c50 81faf168 8207bf78 00000000 tcpip!ARPSendComplete+0xec
80473eec bfd0436e 81e05b30 8207bf78 00000000 NDIS!NdisMSendComplete+0xe1
80473f24 bfd04143 00000003 01fc7c50 80402330
n100nt5!TxQueueFreePacket+0x166
80473f48 bfd05e28 81fcc6f4 81e05b30 00000000
n100nt5!TxQueueFreeBlocks+0x97
80473f64 bff79974 40fcc428 8046fd60 8046fff0
n100nt5!MiniportHandleInterrupt+0x38
80473f80 804650d4 81fcc708 81fcc6f4 00000000 NDIS!ndisMDpc+0xc8
80473f94 8046506f 0000000e 00000000 00000000 nt!KiRetireDpcList+0x30
80473f9c 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x26

FOLLOWUP_IP:
tcpip!TCPSendComplete+61
bfe3306a 8b3f mov edi,[edi]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tcpip!TCPSendComplete+61

MODULE_NAME: tcpip

IMAGE_NAME: tcpip.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3eaf053b

STACK_COMMAND: .trap ffffffff80473df0 ; kb

BUCKET_ID: 0xD1_tcpip!TCPSendComplete+61

2

I assume you are writing a filter driver on the TCP stack? If so, this was
probably caused by incorrect IRP setup in your driver.

This is processing a DCP in the TCP completion function, or more likely
completion callback. It has dereferenced a null pointer and crashed trying
to use that. I would look at the disassembly of the front of the completion
callback rountine and try to figure out what it is doing, and determine
where it got the zero pointer. You are only a few bytes into the completion
routine, so this shouldn’t be too hard to figure out.

Since this is a completion callback, your driver may be on top of tcpip.sys,
and it may be waiting on an event in the dispatch routine, waiting for this
irp to complete. You can look at the other system stacks and see if one is
in your driver waiting on an event. You can also get a printout of the
current irp being processed, and the state of the IRP may tell you something
useful.

----- Original Message -----
From: “Girish Kulkarni (kulkis)”
To: “Windows System Software Devs Interest List”
Sent: Friday, June 04, 2004 12:08 AM
Subject: [ntdev] Crash Dump analysis …

> Hi Gurus,
>
> I have a crash dump to analyze… the question I have is …
>
> 1. If I look at the stack trace, I don’t see my driver listed. I am not
> sure if the problem was caused by my driver, or is actually a bug in
> tcpip.sys (which i doubt). So, how can I figure that out ? I don’t have
> much experience with looking at crash dumps, and was looking at
> pointers, suggestions, to proceed with this …
>
> Any help, pointers is appreciated.
>
> Thanks,
> -g
>
>
>
> kd> !analyze -v
> *****************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *****************************************************************
>
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pagable (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: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: bfe3306a, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 00000000
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> tcpip!TCPSendComplete+61
> bfe3306a 8b3f mov edi,[edi]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> TRAP_FRAME: 80473df0 – (.trap ffffffff80473df0)
> ErrCode = 00000000
> eax=00000000 ebx=00000002 ecx=adfb00bb edx=adfa00ba esi=816ae8c0
> edi=00000000
> eip=bfe3306a esp=80473e64 ebp=80473e74 iopl=0 nv up ei ng nz ac
> pe cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010293
> tcpip!TCPSendComplete+61:
> bfe3306a 8b3f mov edi,[edi]
> ds:0023:00000000=???
> Resetting default context
>
> LAST_CONTROL_TRANSFER: from bfe32682 to bfe3306a
>
> STACK_TEXT:
> 80473e74 bfe32682 816ae8c0 816af688 00000000 tcpip!TCPSendComplete+0x61
> 80473eac bfe32536 81fa97c8 00000000 00000000 tcpip!IPSendComplete+0x13c
> 80473ecc bff87c50 81faf168 8207bf78 00000000 tcpip!ARPSendComplete+0xec
> 80473eec bfd0436e 81e05b30 8207bf78 00000000 NDIS!NdisMSendComplete+0xe1
> 80473f24 bfd04143 00000003 01fc7c50 80402330
> n100nt5!TxQueueFreePacket+0x166
> 80473f48 bfd05e28 81fcc6f4 81e05b30 00000000
> n100nt5!TxQueueFreeBlocks+0x97
> 80473f64 bff79974 40fcc428 8046fd60 8046fff0
> n100nt5!MiniportHandleInterrupt+0x38
> 80473f80 804650d4 81fcc708 81fcc6f4 00000000 NDIS!ndisMDpc+0xc8
> 80473f94 8046506f 0000000e 00000000 00000000 nt!KiRetireDpcList+0x30
> 80473f9c 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x26
>
>
> FOLLOWUP_IP:
> tcpip!TCPSendComplete+61
> bfe3306a 8b3f mov edi,[edi]
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: tcpip!TCPSendComplete+61
>
> MODULE_NAME: tcpip
>
> IMAGE_NAME: tcpip.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3eaf053b
>
> STACK_COMMAND: .trap ffffffff80473df0 ; kb
>
> BUCKET_ID: 0xD1_tcpip!TCPSendComplete+61
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@earthlink.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Loren,
I have a virtual scsi miniport, which sends-receives data over a TCP
connection.
Yes, I too suspect the completion callback … I will walk through that
…

-g

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Friday, June 04, 2004 12:51 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Crash Dump analysis …

I assume you are writing a filter driver on the TCP stack? If so, this
was probably caused by incorrect IRP setup in your driver.

This is processing a DCP in the TCP completion function, or more likely
completion callback. It has dereferenced a null pointer and crashed
trying to use that. I would look at the disassembly of the front of the
completion callback rountine and try to figure out what it is doing, and
determine where it got the zero pointer. You are only a few bytes into
the completion routine, so this shouldn’t be too hard to figure out.

Since this is a completion callback, your driver may be on top of
tcpip.sys, and it may be waiting on an event in the dispatch routine,
waiting for this irp to complete. You can look at the other system
stacks and see if one is in your driver waiting on an event. You can
also get a printout of the current irp being processed, and the state of
the IRP may tell you something useful.

----- Original Message -----
From: “Girish Kulkarni (kulkis)”
To: “Windows System Software Devs Interest List”
Sent: Friday, June 04, 2004 12:08 AM
Subject: [ntdev] Crash Dump analysis …

> Hi Gurus,
>
> I have a crash dump to analyze… the question I have is …
>
> 1. If I look at the stack trace, I don’t see my driver listed. I am
> not sure if the problem was caused by my driver, or is actually a bug
> in tcpip.sys (which i doubt). So, how can I figure that out ? I don’t
> have much experience with looking at crash dumps, and was looking at
> pointers, suggestions, to proceed with this …
>
> Any help, pointers is appreciated.
>
> Thanks,
> -g
>
>
>
> kd> !analyze -v
> ********
>
>
>
>
> * Bugcheck Analysis
>
>
>
>
> *******
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pagable (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: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: bfe3306a, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 00000000
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> tcpip!TCPSendComplete+61
> bfe3306a 8b3f mov edi,[edi]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> TRAP_FRAME: 80473df0 – (.trap ffffffff80473df0)
> ErrCode = 00000000
> eax=00000000 ebx=00000002 ecx=adfb00bb edx=adfa00ba esi=816ae8c0
> edi=00000000
> eip=bfe3306a esp=80473e64 ebp=80473e74 iopl=0 nv up ei ng nz
ac
> pe cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010293
> tcpip!TCPSendComplete+61:
> bfe3306a 8b3f mov edi,[edi]
> ds:0023:00000000=???
> Resetting default context
>
> LAST_CONTROL_TRANSFER: from bfe32682 to bfe3306a
>
> STACK_TEXT:
> 80473e74 bfe32682 816ae8c0 816af688 00000000
> tcpip!TCPSendComplete+0x61 80473eac bfe32536 81fa97c8 00000000
> 00000000 tcpip!IPSendComplete+0x13c 80473ecc bff87c50 81faf168
> 8207bf78 00000000 tcpip!ARPSendComplete+0xec 80473eec bfd0436e
> 81e05b30 8207bf78 00000000 NDIS!NdisMSendComplete+0xe1 80473f24
> bfd04143 00000003 01fc7c50 80402330 n100nt5!TxQueueFreePacket+0x166
> 80473f48 bfd05e28 81fcc6f4 81e05b30 00000000
> n100nt5!TxQueueFreeBlocks+0x97 80473f64 bff79974 40fcc428 8046fd60
> 8046fff0 n100nt5!MiniportHandleInterrupt+0x38
> 80473f80 804650d4 81fcc708 81fcc6f4 00000000 NDIS!ndisMDpc+0xc8
> 80473f94 8046506f 0000000e 00000000 00000000 nt!KiRetireDpcList+0x30
> 80473f9c 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x26
>
>
> FOLLOWUP_IP:
> tcpip!TCPSendComplete+61
> bfe3306a 8b3f mov edi,[edi]
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: tcpip!TCPSendComplete+61
>
> MODULE_NAME: tcpip
>
> IMAGE_NAME: tcpip.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3eaf053b
>
> STACK_COMMAND: .trap ffffffff80473df0 ; kb
>
> BUCKET_ID: 0xD1_tcpip!TCPSendComplete+61
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@earthlink.net To
> unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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