An interesting memory dump

NTDEV
1

Hi, Folks
My box crashed last night due to some weird problem. There is not any
development-phase driver running on my box.So, I just want to find out
what cause the BSOD.
Below is the windbg output.Does anyone could help me to figure out the
root cause of this problem?

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: 77777807, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f57d85e3, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 77777807

CURRENT_IRQL: 2

FAULTING_IP:
afd!AfdIndicatePollEventReal+9b
f57d85e3 ff4008 inc dword ptr [eax+0x8]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from f57d85e3 to 804e287f

STACK_TEXT:
f794dec8 f57d85e3 badb0d00 82ddf8f8 00000000 nt!KiTrap0E+0x233
f794df6c f57e39ed 827ae008 00000001 00000000
afd!AfdIndicatePollEventReal+0x9b
f794dfa0 f5839271 00000000 82726008 f5839271
afd!AfdReceiveDatagramEventHandler+0x334
f794e034 f583951a 82726008 f794e0a4 00000000 tcpip6!UDPDeliver+0x1e8
f794e07c f58262cc 82726008 00000560 f794e0f0 tcpip6!UDPReceive+0x20c
f794e08c f582eeb3 f794e011 82b8e698 82cc98e8 tcpip6!IPv6Receive+0x53
f794e0f0 f7354e61 82cb0f00 82b8e698 f6ac7b40 tcpip6!LanReceivePacket+0x15c
f794e144 f6ac201d 00d8b228 82cdaaf0 00000001
NDIS!ethFilterDprIndicateReceivePacket+0x468
f794e158 f6ac21b4 82d96ad0 82cdaaf0 00000001 psched!PsFlushReceiveQueue+0x15
f794e17c f6ac25f9 82cf0010 00000000 82d96ad0
psched!PsEnqueueReceivePacket+0xda
f794e194 f7354d40 82cf0008 82bbe4b8 82bb5000 psched!ClReceiveComplete+0x13
f794e1e4 f78092f7 00d8b228 f794eb04 00000001
NDIS!ethFilterDprIndicateReceivePacket+0x5a4
f794efa0 f7809053 82bb5000 f794efd0 00000000
fetnd5!MiniportHandleInterrupt+0x3d1
f794efb8 f734af09 82bb5000 82f91bc0 82f91e24
fetnd5!MiniportHandleInterrupt+0x12d
f794efd0 804dcbd4 82bb507c 82bb5068 00000000 NDIS!ndisMDpcX+0x21
f794eff4 804dc89e b8aead54 00000000 00000000 nt!KiRetireDpcList+0x46
f794eff8 b8aead54 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2a
WARNING: Frame IP not in any known module. Following frames may be wrong.
804dc89e 00000000 00000009 bb835675 00000128 0xb8aead54

STACK_COMMAND: kb

FOLLOWUP_IP:
tcpip6!UDPDeliver+1e8
f5839271 85ff test edi,edi

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 3

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tcpip6!UDPDeliver+1e8

MODULE_NAME: tcpip6

IMAGE_NAME: tcpip6.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107d2a

FAILURE_BUCKET_ID: 0xD1_W_tcpip6!UDPDeliver+1e8

BUCKET_ID: 0xD1_W_tcpip6!UDPDeliver+1e8

Followup: MachineOwner

2

It will make it much more likely that you get a helpful response if you
could tell use a couple more details:

  1. What is the name and purpose of your driver.
  2. What OS / version / service pack is this.
  3. Is this a multi-processor system?
  4. Is your driver in the stack-back trace? (My guess is no unless your
    driver is the miniport).
  5. Can you reproduce this crash?
  6. Have you run your driver on the Checked Build of the OS with driver
    verifier turned on for yours and all interacting drivers?

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Sunday, June 11, 2006 5:20 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] An interesting memory dump

Hi, Folks
My box crashed last night due to some weird problem. There is not any
development-phase driver running on my box.So, I just want to find out what
cause the BSOD.
Below is the windbg output.Does anyone could help me to figure out the root
cause of this problem?

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: 77777807, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f57d85e3, address which referenced memory

3

David,
Thanks for your help. This is irrelevant to my driver. I just want to
find out is this a bug for the OS driver.

David R. Cattley дµÀ:

It will make it much more likely that you get a helpful response if you
could tell use a couple more details:

  1. What is the name and purpose of your driver.
    Actually, I don’t develop my driver on this computer. :slight_smile:
  2. What OS / version / service pack is this.
    WinXP sp2
  3. Is this a multi-processor system?
    UP
  4. Is your driver in the stack-back trace? (My guess is no unless your
    driver is the miniport).
    NO
  5. Can you reproduce this crash?
    Emm. When I use VLC, my computer will hang sometimes.
  6. Have you run your driver on the Checked Build of the OS with driver
    verifier turned on for yours and all interacting drivers?
    NO. But I’ll try it.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Sunday, June 11, 2006 5:20 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] An interesting memory dump

Hi, Folks
My box crashed last night due to some weird problem. There is not any
development-phase driver running on my box.So, I just want to find out what
cause the BSOD.
Below is the windbg output.Does anyone could help me to figure out the root
cause of this problem?

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: 77777807, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f57d85e3, address which referenced memory

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

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

AFD and TCPIP6 though not infallable are not likely to be at the root of the
crash you observed. More often than not is will be some other driver that
has corrupted the system. It would not be a stretch, for instance, to have
a driver fail to release a spinlock and cause the elevated IRQL failure
observed in your crash dump and yet not have that driver show up in the
backtrace.

The first step is to figure out if the target address that AFD was trying to
access is legal. In other words, is the address bogus or the IRQL too high.
If the address is bogus, I would suspect memory corruption, an overwrite
error, or heap misuse. If the IRQL is too high, I would suspect a spinlock
violation and since this is AFD, I would look for filter devices attached to
TDI transports or for kernel mode TDI clients.

Sorry, I misread your first post and thought it said you *had* development
phase driver running on it.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hanzhu
Sent: Sunday, June 11, 2006 11:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] An interesting memory dump

David,
Thanks for your help. This is irrelevant to my driver. I just want to find
out is this a bug for the OS driver.

David R. Cattley д??:

It will make it much more likely that you get a helpful response if
you could tell use a couple more details:

  1. What is the name and purpose of your driver.
    Actually, I don’t develop my driver on this computer. :slight_smile:
  2. What OS / version / service pack is this.
    WinXP sp2
  3. Is this a multi-processor system?
    UP
  4. Is your driver in the stack-back trace? (My guess is no unless
    your driver is the miniport).
    NO
  5. Can you reproduce this crash?
    Emm. When I use VLC, my computer will hang sometimes.
  6. Have you run your driver on the Checked Build of the OS with
    driver verifier turned on for yours and all interacting drivers?
    NO. But I’ll try it.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Sunday, June 11, 2006 5:20 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] An interesting memory dump

Hi, Folks
My box crashed last night due to some weird problem. There is not any
development-phase driver running on my box.So, I just want to find out
what cause the BSOD.
Below is the windbg output.Does anyone could help me to figure out the
root cause of this problem?

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: 77777807, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f57d85e3, address which referenced memory

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Thanks a lot for your guideline, David.
Actually, the memory address for the BSOD is totally invalid. The pmd
for this address contains 0x0. It should be some vendor’s driver imports
this bug for the systems since only when I install vlc(a open source lan
video palyer) to my system I can observe this problem.
I’ll check the code for vlc if I have time.
Anyway, thanks you for your thorough explains to how to debug this
problem, David.

Best Regards,
hanzhu

David R. Cattley дµÀ:

AFD and TCPIP6 though not infallable are not likely to be at the root of the
crash you observed. More often than not is will be some other driver that
has corrupted the system. It would not be a stretch, for instance, to have
a driver fail to release a spinlock and cause the elevated IRQL failure
observed in your crash dump and yet not have that driver show up in the
backtrace.

The first step is to figure out if the target address that AFD was trying to
access is legal. In other words, is the address bogus or the IRQL too high.
If the address is bogus, I would suspect memory corruption, an overwrite
error, or heap misuse. If the IRQL is too high, I would suspect a spinlock
violation and since this is AFD, I would look for filter devices attached to
TDI transports or for kernel mode TDI clients.

Sorry, I misread your first post and thought it said you *had* development
phase driver running on it.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hanzhu
Sent: Sunday, June 11, 2006 11:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] An interesting memory dump

David,
Thanks for your help. This is irrelevant to my driver. I just want to find
out is this a bug for the OS driver.

David R. Cattley дµÀ:
> It will make it much more likely that you get a helpful response if
> you could tell use a couple more details:
>
> 1. What is the name and purpose of your driver.
Actually, I don’t develop my driver on this computer. :slight_smile:
> 2. What OS / version / service pack is this.
WinXP sp2
> 3. Is this a multi-processor system?
UP
> 4. Is your driver in the stack-back trace? (My guess is no unless
> your driver is the miniport).
NO
> 5. Can you reproduce this crash?
Emm. When I use VLC, my computer will hang sometimes.
> 6. Have you run your driver on the Checked Build of the OS with
> driver verifier turned on for yours and all interacting drivers?
NO. But I’ll try it.
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> Sent: Sunday, June 11, 2006 5:20 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] An interesting memory dump
>
> Hi, Folks
> My box crashed last night due to some weird problem. There is not any
> development-phase driver running on my box.So, I just want to find out
> what cause the BSOD.
> Below is the windbg output.Does anyone could help me to figure out the
> root cause of this problem?
>
> 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: 77777807, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000001, value 0 = read operation, 1 = write operation
> Arg4: f57d85e3, address which referenced memory
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

David R. Cattley wrote:

AFD and TCPIP6 though not infallable are not likely to be at the root of the
crash you observed. More often than not is will be some other driver that
has corrupted the system. It would not be a stretch, for instance, to have
a driver fail to release a spinlock and cause the elevated IRQL failure
observed in your crash dump and yet not have that driver show up in the
backtrace.

The first step is to figure out if the target address that AFD was trying to
access is legal. In other words, is the address bogus or the IRQL too high.

The address was 77777FFF. That’s too weird to be valid.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

If anyone is interest on this issue, I can send the memory dump file to
him. Just as Tim pointed out, it’s weird for Afd.sys to access such a
strange address(user space address?) and this address is invalid
totally. I suppose afd.sys should do all the sanity check before access
the user space address directly. So, it must be some other drivers who
have injected this bug to afd.sys. I’m afraid the miniport could be the
evil.

Best Regards,
hanzhu

Tim Roberts дµÀ:

David R. Cattley wrote:

> AFD and TCPIP6 though not infallable are not likely to be at the root of the
> crash you observed. More often than not is will be some other driver that
> has corrupted the system. It would not be a stretch, for instance, to have
> a driver fail to release a spinlock and cause the elevated IRQL failure
> observed in your crash dump and yet not have that driver show up in the
> backtrace.
>
> The first step is to figure out if the target address that AFD was trying to
> access is legal. In other words, is the address bogus or the IRQL too high.
>
>

The address was 77777FFF. That’s too weird to be valid.