IRQL_NOT_LESS_OR_EQUAL from System thread in DTM test cycle

Charles · March 5, 2010, 7:49pm

Hi All,

I’m working on NDIS miniport driver, and I encounter the following BSOD when
running DTM tests for WHQL on Windows XP in Networking LAN test of NDISTest 6.0, the driver was developed in NDIS 5. Here is the output from WinDbg trace, Any suggestions how can I proceed to fix that?
I did an NDIS thread stack trace, and the result is at the end of this post:

Thanks.

kd> !analyze -v
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 805fa283, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805fa283, address which referenced memory

Debugging Details:

READ_ADDRESS: 805fa283

CURRENT_IRQL: ff

FAULTING_IP:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: f78cdfe8 – (.trap 0xfffffffff78cdfe8)
ErrCode = 00000010
eax=805fa283 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=805fa283 esp=f78ce05c ebp=f78ceddc iopl=0 nv up di pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010046
nt!PspSystemThreadStartup+0x52:
805fa283 ff75ec push dword ptr [ebp-14h] ss:0010:f78cedc8=f78ce078
Resetting default scope

LAST_CONTROL_TRANSFER: from 805fa283 to 804e187f

FAILED_INSTRUCTION_ADDRESS:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

STACK_TEXT:
f78cdfe8 805fa283 badb0d00 00000000 ffffffff nt!KiTrap0E+0x233
f78ceddc 804f88ea 804e4196 00000001 00000000 nt!PspSystemThreadStartup+0x52
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiTrap0E+233
804e187f f7457000000200 test dword ptr [ebp+70h],20000h

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!KiTrap0E+233

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a78505a

FAILURE_BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

Followup: MachineOwner

kd> !stacks 1 ndis
Proc.Thread .Thread Ticks ThreadState Blocker
[89b28830 System]
4.00006c 89af38e8 0000010 Blocked NDIS!ndisWorkerThread+0x30
4.000a1c 892a5810 0000010 READY nt!KiDispatchInterrupt+0x7f

OSR_Community_User · March 8, 2010, 10:28am

Did your driver post workitem to worker thread (system or yours ) ?

Did you send a irp with a pointer to the buffer allocated in the thread stack ? Your dump indicates crash happens when a variable in stack is accessed. This address is possible invalid because of stack unwinding.

From my experience , You might not correctly handle the case that status_pending is returned as IRP sending .

Good luck.

OSR_Community_User · March 8, 2010, 12:35pm

If I remember correctly, IRQL = 0xff means that interrupts were disabled. So, unless I am mistaken about that, you should look for some code that disables interrupts and forgets to re-enable them.

I would do a “dps f78ced00”, followed by “dps” without parameters a few times, and look for some symbols pointing to the code that ran recently in the current thread. Then I would examine that source code, looking for interrupts being disabled.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Friday, March 05, 2010 4:50 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRQL_NOT_LESS_OR_EQUAL from System thread in DTM test cycle

Hi All,

I’m working on NDIS miniport driver, and I encounter the following BSOD when
running DTM tests for WHQL on Windows XP in Networking LAN test of NDISTest 6.0, the driver was developed in NDIS 5. Here is the output from WinDbg trace, Any suggestions how can I proceed to fix that?
I did an NDIS thread stack trace, and the result is at the end of this post:

Thanks.

kd> !analyze -v
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 805fa283, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805fa283, address which referenced memory

Debugging Details:

READ_ADDRESS: 805fa283

CURRENT_IRQL: ff

FAULTING_IP:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: f78cdfe8 – (.trap 0xfffffffff78cdfe8)
ErrCode = 00000010
eax=805fa283 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=805fa283 esp=f78ce05c ebp=f78ceddc iopl=0 nv up di pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010046
nt!PspSystemThreadStartup+0x52:
805fa283 ff75ec push dword ptr [ebp-14h] ss:0010:f78cedc8=f78ce078
Resetting default scope

LAST_CONTROL_TRANSFER: from 805fa283 to 804e187f

FAILED_INSTRUCTION_ADDRESS:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

STACK_TEXT:
f78cdfe8 805fa283 badb0d00 00000000 ffffffff nt!KiTrap0E+0x233
f78ceddc 804f88ea 804e4196 00000001 00000000 nt!PspSystemThreadStartup+0x52
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiTrap0E+233
804e187f f7457000000200 test dword ptr [ebp+70h],20000h

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!KiTrap0E+233

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a78505a

FAILURE_BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

Followup: MachineOwner

kd> !stacks 1 ndis
Proc.Thread .Thread Ticks ThreadState Blocker
[89b28830 System]
4.00006c 89af38e8 0000010 Blocked NDIS!ndisWorkerThread+0x30
4.000a1c 892a5810 0000010 READY nt!KiDispatchInterrupt+0x7f

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Mark_Roddy · March 8, 2010, 1:30pm

irql values from xp in windbg are never accurate as far as I can tell.

Mark Roddy

On Mon, Mar 8, 2010 at 12:34 PM, Daniel Mihai wrote:

> If I remember correctly, IRQL = 0xff means that interrupts were disabled.
> So, unless I am mistaken about that, you should look for some code that
> disables interrupts and forgets to re-enable them.
>
> I would do a “dps f78ced00”, followed by “dps” without parameters a few
> times, and look for some symbols pointing to the code that ran recently in
> the current thread. Then I would examine that source code, looking for
> interrupts being disabled.
>
> Dan
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
> Sent: Friday, March 05, 2010 4:50 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] IRQL_NOT_LESS_OR_EQUAL from System thread in DTM test
> cycle
>
> Hi All,
>
> I’m working on NDIS miniport driver, and I encounter the following BSOD
> when
> running DTM tests for WHQL on Windows XP in Networking LAN test of NDISTest
> 6.0, the driver was developed in NDIS 5. Here is the output from WinDbg
> trace, Any suggestions how can I proceed to fix that?
> I did an NDIS thread stack trace, and the result is at the end of this
> post:
>
> Thanks.
>
> kd> !analyze -v
> IRQL_NOT_LESS_OR_EQUAL (a)
> 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 a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: 805fa283, memory referenced
> Arg2: 000000ff, IRQL
> Arg3: 00000000, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation
> (only on chips which support this level of status)
> Arg4: 805fa283, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 805fa283
>
> CURRENT_IRQL: ff
>
> FAULTING_IP:
> nt!PspSystemThreadStartup+52
> 805fa283 ff75ec push dword ptr [ebp-14h]
>
> DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
>
> BUGCHECK_STR: 0xA
>
> PROCESS_NAME: System
>
> TRAP_FRAME: f78cdfe8 – (.trap 0xfffffffff78cdfe8)
> ErrCode = 00000010
> eax=805fa283 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000
> edi=00000000
> eip=805fa283 esp=f78ce05c ebp=f78ceddc iopl=0 nv up di pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010046
> nt!PspSystemThreadStartup+0x52:
> 805fa283 ff75ec push dword ptr [ebp-14h]
> ss:0010:f78cedc8=f78ce078
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 805fa283 to 804e187f
>
> FAILED_INSTRUCTION_ADDRESS:
> nt!PspSystemThreadStartup+52
> 805fa283 ff75ec push dword ptr [ebp-14h]
>
> STACK_TEXT:
> f78cdfe8 805fa283 badb0d00 00000000 ffffffff nt!KiTrap0E+0x233
> f78ceddc 804f88ea 804e4196 00000001 00000000 nt!PspSystemThreadStartup+0x52
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!KiTrap0E+233
> 804e187f f7457000000200 test dword ptr [ebp+70h],20000h
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: nt!KiTrap0E+233
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntoskrnl.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4a78505a
>
> FAILURE_BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233
>
> BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233
>
> Followup: MachineOwner
> ---------
>
>
>
> kd> !stacks 1 ndis
> Proc.Thread .Thread Ticks ThreadState Blocker
> [89b28830 System]
> 4.00006c 89af38e8 0000010 Blocked NDIS!ndisWorkerThread+0x30
> 4.000a1c 892a5810 0000010 READY nt!KiDispatchInterrupt+0x7f
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Scott_Noone_OSR · March 8, 2010, 1:46pm

The IRQL reported in the bugcheck parameters should be correct though since
that is captured as part of collecting info for the crash (and Dan’s
recollection of 0xFF meaning interrupt enabled bit is cleared is correct).

You’re right though that !irql is useless on XP, luckily later versions of
the command actually say that instead of always just reporting
PASSIVE_LEVEL.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Mark Roddy” wrote in message news:xxxxx@ntdev…
irql values from xp in windbg are never accurate as far as I can tell.

Mark Roddy

On Mon, Mar 8, 2010 at 12:34 PM, Daniel Mihai wrote:

If I remember correctly, IRQL = 0xff means that interrupts were disabled.
So, unless I am mistaken about that, you should look for some code that
disables interrupts and forgets to re-enable them.

I would do a “dps f78ced00”, followed by “dps” without parameters a few
times, and look for some symbols pointing to the code that ran recently in
the current thread. Then I would examine that source code, looking for
interrupts being disabled.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Friday, March 05, 2010 4:50 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRQL_NOT_LESS_OR_EQUAL from System thread in DTM test cycle

Hi All,

I’m working on NDIS miniport driver, and I encounter the following BSOD when
running DTM tests for WHQL on Windows XP in Networking LAN test of NDISTest
6.0, the driver was developed in NDIS 5. Here is the output from WinDbg
trace, Any suggestions how can I proceed to fix that?
I did an NDIS thread stack trace, and the result is at the end of this post:

Thanks.

kd> !analyze -v
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 805fa283, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation
(only on chips which support this level of status)
Arg4: 805fa283, address which referenced memory

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

READ_ADDRESS: 805fa283

CURRENT_IRQL: ff

FAULTING_IP:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: f78cdfe8 – (.trap 0xfffffffff78cdfe8)
ErrCode = 00000010
eax=805fa283 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000
edi=00000000
eip=805fa283 esp=f78ce05c ebp=f78ceddc iopl=0 nv up di pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010046
nt!PspSystemThreadStartup+0x52:
805fa283 ff75ec push dword ptr [ebp-14h]
ss:0010:f78cedc8=f78ce078
Resetting default scope

LAST_CONTROL_TRANSFER: from 805fa283 to 804e187f

FAILED_INSTRUCTION_ADDRESS:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

STACK_TEXT:
f78cdfe8 805fa283 badb0d00 00000000 ffffffff nt!KiTrap0E+0x233
f78ceddc 804f88ea 804e4196 00000001 00000000 nt!PspSystemThreadStartup+0x52
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiTrap0E+233
804e187f f7457000000200 test dword ptr [ebp+70h],20000h

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!KiTrap0E+233

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a78505a

FAILURE_BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

Followup: MachineOwner
---------

kd> !stacks 1 ndis
Proc.Thread .Thread Ticks ThreadState Blocker
[89b28830 System]
4.00006c 89af38e8 0000010 Blocked NDIS!ndisWorkerThread+0x30
4.000a1c 892a5810 0000010 READY nt!KiDispatchInterrupt+0x7f

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

OSR_Community_User · March 8, 2010, 1:47pm

The value 0xff below appears to have come from the OS kernel (from KiTrap0E), at runtime, so it shouldn’t be related to windbg.

Dan

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, March 08, 2010 10:29 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IRQL_NOT_LESS_OR_EQUAL from System thread in DTM test cycle

irql values from xp in windbg are never accurate as far as I can tell.

Mark Roddy

On Mon, Mar 8, 2010 at 12:34 PM, Daniel Mihai > wrote:
If I remember correctly, IRQL = 0xff means that interrupts were disabled. So, unless I am mistaken about that, you should look for some code that disables interrupts and forgets to re-enable them.

I would do a “dps f78ced00”, followed by “dps” without parameters a few times, and look for some symbols pointing to the code that ran recently in the current thread. Then I would examine that source code, looking for interrupts being disabled.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com mailto:xxxxx [mailto:xxxxx@lists.osr.com mailto:xxxxx] On Behalf Of xxxxx@yahoo.com mailto:xxxxx
Sent: Friday, March 05, 2010 4:50 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRQL_NOT_LESS_OR_EQUAL from System thread in DTM test cycle

Hi All,

I’m working on NDIS miniport driver, and I encounter the following BSOD when
running DTM tests for WHQL on Windows XP in Networking LAN test of NDISTest 6.0, the driver was developed in NDIS 5. Here is the output from WinDbg trace, Any suggestions how can I proceed to fix that?
I did an NDIS thread stack trace, and the result is at the end of this post:

Thanks.

kd> !analyze -v
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 805fa283, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805fa283, address which referenced memory

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

READ_ADDRESS: 805fa283

CURRENT_IRQL: ff

FAULTING_IP:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: f78cdfe8 – (.trap 0xfffffffff78cdfe8)
ErrCode = 00000010
eax=805fa283 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=805fa283 esp=f78ce05c ebp=f78ceddc iopl=0 nv up di pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010046
nt!PspSystemThreadStartup+0x52:
805fa283 ff75ec push dword ptr [ebp-14h] ss:0010:f78cedc8=f78ce078
Resetting default scope

LAST_CONTROL_TRANSFER: from 805fa283 to 804e187f

FAILED_INSTRUCTION_ADDRESS:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

STACK_TEXT:
f78cdfe8 805fa283 badb0d00 00000000 ffffffff nt!KiTrap0E+0x233
f78ceddc 804f88ea 804e4196 00000001 00000000 nt!PspSystemThreadStartup+0x52
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiTrap0E+233
804e187f f7457000000200 test dword ptr [ebp+70h],20000h

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!KiTrap0E+233

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a78505a

FAILURE_BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

Followup: MachineOwner
---------

kd> !stacks 1 ndis
Proc.Thread .Thread Ticks ThreadState Blocker
[89b28830 System]
4.00006c 89af38e8 0000010 Blocked NDIS!ndisWorkerThread+0x30
4.000a1c 892a5810 0000010 READY nt!KiDispatchInterrupt+0x7f

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Ken_Johnson · March 8, 2010, 3:09pm

They would be accurate only during live debugging pre-srv03, IIRC.

S

From: Mark Roddy
Sent: Monday, March 08, 2010 10:30
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IRQL_NOT_LESS_OR_EQUAL from System thread in DTM test cycle

irql values from xp in windbg are never accurate as far as I can tell.

Mark Roddy

On Mon, Mar 8, 2010 at 12:34 PM, Daniel Mihai > wrote:
If I remember correctly, IRQL = 0xff means that interrupts were disabled. So, unless I am mistaken about that, you should look for some code that disables interrupts and forgets to re-enable them.

I would do a “dps f78ced00”, followed by “dps” without parameters a few times, and look for some symbols pointing to the code that ran recently in the current thread. Then I would examine that source code, looking for interrupts being disabled.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com mailto:xxxxx [mailto:xxxxx@lists.osr.com mailto:xxxxx] On Behalf Of xxxxx@yahoo.com mailto:xxxxx
Sent: Friday, March 05, 2010 4:50 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRQL_NOT_LESS_OR_EQUAL from System thread in DTM test cycle

Hi All,

I’m working on NDIS miniport driver, and I encounter the following BSOD when
running DTM tests for WHQL on Windows XP in Networking LAN test of NDISTest 6.0, the driver was developed in NDIS 5. Here is the output from WinDbg trace, Any suggestions how can I proceed to fix that?
I did an NDIS thread stack trace, and the result is at the end of this post:

Thanks.

kd> !analyze -v
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 805fa283, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805fa283, address which referenced memory

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

READ_ADDRESS: 805fa283

CURRENT_IRQL: ff

FAULTING_IP:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: f78cdfe8 – (.trap 0xfffffffff78cdfe8)
ErrCode = 00000010
eax=805fa283 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=805fa283 esp=f78ce05c ebp=f78ceddc iopl=0 nv up di pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010046
nt!PspSystemThreadStartup+0x52:
805fa283 ff75ec push dword ptr [ebp-14h] ss:0010:f78cedc8=f78ce078
Resetting default scope

LAST_CONTROL_TRANSFER: from 805fa283 to 804e187f

FAILED_INSTRUCTION_ADDRESS:
nt!PspSystemThreadStartup+52
805fa283 ff75ec push dword ptr [ebp-14h]

STACK_TEXT:
f78cdfe8 805fa283 badb0d00 00000000 ffffffff nt!KiTrap0E+0x233
f78ceddc 804f88ea 804e4196 00000001 00000000 nt!PspSystemThreadStartup+0x52
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiTrap0E+233
804e187f f7457000000200 test dword ptr [ebp+70h],20000h

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!KiTrap0E+233

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4a78505a

FAILURE_BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

BUCKET_ID: 0xA_VRF_CODE_AV_BAD_IP_nt!KiTrap0E+233

Followup: MachineOwner
---------

kd> !stacks 1 ndis
Proc.Thread .Thread Ticks ThreadState Blocker
[89b28830 System]
4.00006c 89af38e8 0000010 Blocked NDIS!ndisWorkerThread+0x30
4.000a1c 892a5810 0000010 READY nt!KiDispatchInterrupt+0x7f

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Charles · March 8, 2010, 7:23pm

Hi all,

I am still digging the driver source to root cause the 0xff irq in the crash dump analysis. But here is some additional info:
I noticed the crash is 100% reproducible, and it always happened when NDISTest has finished broadcasting 10000 packets and tried to cancel this operation and clean up, then the same crash popped up with the same stop error. Does that mean I should check more on the IRP status processing and returning?
Now, here is the result of ‘dps’ commands:
kd> dps f78ced00
f78ced00 e1316608
f78ced04 8931ea00
f78ced08 00000000
f78ced0c ffffffff
f78ced10 00000001
f78ced14 89afa618
f78ced18 00000000
f78ced1c 89afa618
f78ced20 89ab5ed8
f78ced24 00000000
f78ced28 00000000
f78ced2c e1d1cec0
f78ced30 008ced50
f78ced34 f78ced50
f78ced38 805ed3cd nt!PiProcessTargetDeviceEvent+0x2a
f78ced3c f78ced70
f78ced40 806f0778 hal!ExReleaseFastMutex
f78ced44 e1e1f838
f78ced48 00000000
f78ced4c 00000000
f78ced50 f78ced74
f78ced54 805a0159 nt!PiWalkDeviceList+0x10f
f78ced58 f78ced70
f78ced5c 893d0c78
f78ced60 805622fc nt!ExWorkerQueue+0x3c
f78ced64 89b268b8
f78ced68 8056230c nt!ExWorkerQueue+0x4c
f78ced6c f78cedac
f78ced70 e1e1f838
f78ced74 f78cedac
f78ced78 804e426b nt!ExpWorkerThread+0x100
f78ced7c 893d0c78
kd> dps
f78ced80 00000000
f78ced84 89b268b8
f78ced88 00000000
f78ced8c 00000000
f78ced90 00000000
f78ced94 00000001
f78ced98 80562334 nt!ExWorkerQueue+0x74
f78ced9c 00000000
f78ceda0 89b268b8
f78ceda4 00000000
f78ceda8 805a00c8 nt!PiWalkDeviceList
f78cedac f78ceddc
f78cedb0 8057c9ca nt!PspSystemThreadStartup+0x34
f78cedb4 893d0c78
f78cedb8 00000000
f78cedbc 00000000
f78cedc0 00000000
f78cedc4 f78cedb8
f78cedc8 f78ce078
f78cedcc ffffffff
f78cedd0 804e2490 nt!_except_handler3
f78cedd4 804f8ab0 nt!ObWatchHandles+0x62c
f78cedd8 00000000
f78ceddc 00000000
f78cede0 804f88ea nt!KiThreadStartup+0x16
f78cede4 804e4196 nt!ExpWorkerThread
f78cede8 00000001
f78cedec 00000000
f78cedf0 0000027f
f78cedf4 00000000
f78cedf8 00000000
f78cedfc 00000000
kd> !irql
nt!_KPRCB.DebuggerSavedIRQL not found, error : 0x4.
Saved IRQL not available prior to Windows Server 2003

>>>>This verifies the !irql command on XP:-)
But I don’t see anything specific to the interrupts enable/disable here. I am still searching to code to see if interrupts are not enabled/disabled properly.

Many thanks to all.
Charles

Alex_Grig · March 8, 2010, 7:46pm

I think this is because you tried to execute pageable code with interrupts disabled or on elevated IRQL, while the DriverVerifier did its IRQL check routine: marked all pageable memory non-present.

In the analysis, you see that faulting IP is the same as faulted memory address, and the actual code is shown by the debugger, which means it’s actually present in memory.

Alex_Grig · March 8, 2010, 8:07pm

More on that. The pagable code itself belongs to PspSystemThreadStartup exception handler. It looks like some other exception happened in your code at elevated IRQL (which should have been relegated to PspUnhandledExceptionInSystemThread called by this handler), but the code is marked non-present by DriverVerifier. Another strike against paged code.

OSR_Community_User · March 8, 2010, 9:22pm

Regarding IRQL 0xff , You can refer to this link . http://www.osronline.com/article.cfm?article=372