MiniDump for DRIVER_IRQL_NOT_LESS_OR_EQUAL

WINDBG
1

I’ve been a member of the list for a few years, but have only posted a
couple of times. I’ve been asked to look over a mini dump for a Win2k3
Cluster node that is occasionally crashing. I don’t get a lot of
practice troubleshooting memory dumps, so I apologize if this is a
trivial issue.

After looking this over, my assessment is that because arg1 == arg4, and
that the exception occurred when EBP is pushed on the stack for the
setup of KSecDD!SspRc4Key, my thinking is that KSecDD was paged out.
Because IRQL is currently 2, if KSecDD was paged out, execution
transferring to KSecDD would cause this exception. What confuses me
though is that I can look at the address via ‘dd ba3e07e9’. If this
memory address was paged out, shouldn’t I expect to see ?'s instead of
data?

Is my reasoning for the cause of this exception sound? Or am I
overlooking something?

I would really like to build up my troubleshooting skills with Windbg,
so if anyone has any tips for further analysis, I would appreciate it
greatly. Likewise, if I’m completely wrong in my analysis, I would
welcome any tips to get me moving in the correct direction.

Kurt

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

Debugging Details:

READ_ADDRESS: ba3e07e9

CURRENT_IRQL: 2

FAULTING_IP:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from ba3e374c to ba3e07e9

STACK_TEXT:
bacd37f0 ba3e374c 63888255 884441d8 bacd3968 KSecDD!SspRc4Key
bacd3980 80704e9d ba3da85b bacd39d0 ba3e3a0d KSecDD!SspSignSealHelper+0x18c
bacd39b0 80542b4c 00000001 00000000 879d2e70 hal!HalpSendIpi+0xd
bacd39e4 b92e31df b92eb234 bacd3a2c 00000000 nt!ExRemoveHeadNBQueue+0xa0
bacd3a38 b92eb234 bacd3a68 b92e34b5 898f9318
clusnet!CcmpProcessReceivePacket+0x237
87399008 00000000 00000000 00000000 00000000 clusnet!SecurityContexts+0x14

STACK_COMMAND: .bugcheck ; kb

FAILED_INSTRUCTION_ADDRESS:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

FOLLOWUP_IP:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: KSecDD!SspRc4Key+0

MODULE_NAME: KSecDD

IMAGE_NAME: KSecDD.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e7fffc3

FAILURE_BUCKET_ID: 0xD1_CODE_AV_BAD_IP_KSecDD!SspRc4Key+0

BUCKET_ID: 0xD1_CODE_AV_BAD_IP_KSecDD!SspRc4Key+0

Followup: MachineOwner

2

Your reasoning makes sense. I think the page could be on the standby
list. It’s “present” but does take a fault to access it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Kurt Congdon
Sent: Tuesday, June 21, 2005 2:50 PM
To: Kernel Debugging Interest List
Subject: [windbg] MiniDump for DRIVER_IRQL_NOT_LESS_OR_EQUAL

I’ve been a member of the list for a few years, but have only posted a
couple of times. I’ve been asked to look over a mini dump for a Win2k3
Cluster node that is occasionally crashing. I don’t get a lot of
practice troubleshooting memory dumps, so I apologize if this is a
trivial issue.

After looking this over, my assessment is that because arg1 == arg4, and

that the exception occurred when EBP is pushed on the stack for the
setup of KSecDD!SspRc4Key, my thinking is that KSecDD was paged out.
Because IRQL is currently 2, if KSecDD was paged out, execution
transferring to KSecDD would cause this exception. What confuses me
though is that I can look at the address via ‘dd ba3e07e9’. If this
memory address was paged out, shouldn’t I expect to see ?'s instead of
data?

Is my reasoning for the cause of this exception sound? Or am I
overlooking something?

I would really like to build up my troubleshooting skills with Windbg,
so if anyone has any tips for further analysis, I would appreciate it
greatly. Likewise, if I’m completely wrong in my analysis, I would
welcome any tips to get me moving in the correct direction.

Kurt

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

Debugging Details:

READ_ADDRESS: ba3e07e9

CURRENT_IRQL: 2

FAULTING_IP:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from ba3e374c to ba3e07e9

STACK_TEXT:
bacd37f0 ba3e374c 63888255 884441d8 bacd3968 KSecDD!SspRc4Key
bacd3980 80704e9d ba3da85b bacd39d0 ba3e3a0d
KSecDD!SspSignSealHelper+0x18c
bacd39b0 80542b4c 00000001 00000000 879d2e70 hal!HalpSendIpi+0xd
bacd39e4 b92e31df b92eb234 bacd3a2c 00000000 nt!ExRemoveHeadNBQueue+0xa0
bacd3a38 b92eb234 bacd3a68 b92e34b5 898f9318
clusnet!CcmpProcessReceivePacket+0x237
87399008 00000000 00000000 00000000 00000000
clusnet!SecurityContexts+0x14

STACK_COMMAND: .bugcheck ; kb

FAILED_INSTRUCTION_ADDRESS:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

FOLLOWUP_IP:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: KSecDD!SspRc4Key+0

MODULE_NAME: KSecDD

IMAGE_NAME: KSecDD.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e7fffc3

FAILURE_BUCKET_ID: 0xD1_CODE_AV_BAD_IP_KSecDD!SspRc4Key+0

BUCKET_ID: 0xD1_CODE_AV_BAD_IP_KSecDD!SspRc4Key+0

Followup: MachineOwner

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

3

Check out what it says from !pte. Its possible that the page is in
transition, so the debugger picks up on that and lets you see what would
be in that address, even though it may not be valid to use it at
runtime. The output from !pte that you’re looking for is ‘transition:
###’.

As an FYI - you can do ‘.cache nodecodeptes’ to disable this behavior,
but it can have other undesirable effects on your debug session.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Croci, MaryBeth
Sent: Tuesday, June 21, 2005 1:42 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] MiniDump for DRIVER_IRQL_NOT_LESS_OR_EQUAL

Your reasoning makes sense. I think the page could be on the standby
list. It’s “present” but does take a fault to access it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Kurt Congdon
Sent: Tuesday, June 21, 2005 2:50 PM
To: Kernel Debugging Interest List
Subject: [windbg] MiniDump for DRIVER_IRQL_NOT_LESS_OR_EQUAL

I’ve been a member of the list for a few years, but have only posted a
couple of times. I’ve been asked to look over a mini dump for a Win2k3
Cluster node that is occasionally crashing. I don’t get a lot of
practice troubleshooting memory dumps, so I apologize if this is a
trivial issue.

After looking this over, my assessment is that because arg1 == arg4, and

that the exception occurred when EBP is pushed on the stack for the
setup of KSecDD!SspRc4Key, my thinking is that KSecDD was paged out.
Because IRQL is currently 2, if KSecDD was paged out, execution
transferring to KSecDD would cause this exception. What confuses me
though is that I can look at the address via ‘dd ba3e07e9’. If this
memory address was paged out, shouldn’t I expect to see ?'s instead of
data?

Is my reasoning for the cause of this exception sound? Or am I
overlooking something?

I would really like to build up my troubleshooting skills with Windbg,
so if anyone has any tips for further analysis, I would appreciate it
greatly. Likewise, if I’m completely wrong in my analysis, I would
welcome any tips to get me moving in the correct direction.

Kurt

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

Debugging Details:

READ_ADDRESS: ba3e07e9

CURRENT_IRQL: 2

FAULTING_IP:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from ba3e374c to ba3e07e9

STACK_TEXT:
bacd37f0 ba3e374c 63888255 884441d8 bacd3968 KSecDD!SspRc4Key
bacd3980 80704e9d ba3da85b bacd39d0 ba3e3a0d
KSecDD!SspSignSealHelper+0x18c
bacd39b0 80542b4c 00000001 00000000 879d2e70 hal!HalpSendIpi+0xd
bacd39e4 b92e31df b92eb234 bacd3a2c 00000000 nt!ExRemoveHeadNBQueue+0xa0
bacd3a38 b92eb234 bacd3a68 b92e34b5 898f9318
clusnet!CcmpProcessReceivePacket+0x237
87399008 00000000 00000000 00000000 00000000
clusnet!SecurityContexts+0x14

STACK_COMMAND: .bugcheck ; kb

FAILED_INSTRUCTION_ADDRESS:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

FOLLOWUP_IP:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: KSecDD!SspRc4Key+0

MODULE_NAME: KSecDD

IMAGE_NAME: KSecDD.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e7fffc3

FAILURE_BUCKET_ID: 0xD1_CODE_AV_BAD_IP_KSecDD!SspRc4Key+0

BUCKET_ID: 0xD1_CODE_AV_BAD_IP_KSecDD!SspRc4Key+0

Followup: MachineOwner

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

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

4

It seems to me that bug occurs because you access paged function on IRQL
that higher than APC_LEVEL (for example you acquired spin lock before). Are
you using something like line below for function SspRc4Key?
#pragma alloc_text(PAGE, SspRc4Key)
If yes then solution is just straightforward - just remove pragma directive
from your code.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Kurt Congdon
Sent: Tuesday, June 21, 2005 8:50 PM
To: Kernel Debugging Interest List
Subject: [windbg] MiniDump for DRIVER_IRQL_NOT_LESS_OR_EQUAL

I’ve been a member of the list for a few years, but have only
posted a couple of times. I’ve been asked to look over a
mini dump for a Win2k3 Cluster node that is occasionally
crashing. I don’t get a lot of practice troubleshooting
memory dumps, so I apologize if this is a trivial issue.

After looking this over, my assessment is that because arg1
== arg4, and that the exception occurred when EBP is pushed
on the stack for the setup of KSecDD!SspRc4Key, my thinking
is that KSecDD was paged out.
Because IRQL is currently 2, if KSecDD was paged out,
execution transferring to KSecDD would cause this exception.
What confuses me though is that I can look at the address via
‘dd ba3e07e9’. If this memory address was paged out,
shouldn’t I expect to see ?'s instead of data?

Is my reasoning for the cause of this exception sound? Or
am I overlooking something?

I would really like to build up my troubleshooting skills
with Windbg, so if anyone has any tips for further analysis,
I would appreciate it greatly. Likewise, if I’m completely
wrong in my analysis, I would welcome any tips to get me
moving in the correct direction.

Kurt

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

Debugging Details:

READ_ADDRESS: ba3e07e9

CURRENT_IRQL: 2

FAULTING_IP:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from ba3e374c to ba3e07e9

STACK_TEXT:
bacd37f0 ba3e374c 63888255 884441d8 bacd3968 KSecDD!SspRc4Key
bacd3980 80704e9d ba3da85b bacd39d0 ba3e3a0d
KSecDD!SspSignSealHelper+0x18c bacd39b0 80542b4c 00000001
00000000 879d2e70 hal!HalpSendIpi+0xd
bacd39e4 b92e31df b92eb234 bacd3a2c 00000000
nt!ExRemoveHeadNBQueue+0xa0
bacd3a38 b92eb234 bacd3a68 b92e34b5 898f9318
clusnet!CcmpProcessReceivePacket+0x237
87399008 00000000 00000000 00000000 00000000
clusnet!SecurityContexts+0x14

STACK_COMMAND: .bugcheck ; kb

FAILED_INSTRUCTION_ADDRESS:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

FOLLOWUP_IP:
KSecDD!SspRc4Key+0
ba3e07e9 55 push ebp

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: KSecDD!SspRc4Key+0

MODULE_NAME: KSecDD

IMAGE_NAME: KSecDD.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e7fffc3

FAILURE_BUCKET_ID: 0xD1_CODE_AV_BAD_IP_KSecDD!SspRc4Key+0

BUCKET_ID: 0xD1_CODE_AV_BAD_IP_KSecDD!SspRc4Key+0

Followup: MachineOwner

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