Puzzling crash @ high IRQL

NTFSD
1

I was doing some testing with my redirector and I got this crash
at high IRQL… the puzzling thing is, the IRQL is 0x1c, my driver
never raises IRQL, and the memory location it was accessing is valid
in the debugger.

This happened running under the driver verifier, with everything
except low resource turned on.

This is the stack trace (I omitted the ebp and retaddr
columns so it wouldn’t wrap in email):

00000000 00000000 00000000 nt!KeWaitForSingleObject+0xeb
825c6e7c 00000000 00000000 nt!VerifierKeWaitForSingleObject+0x54
820603f8 00000002 81f15500 VdsSftpMrx!WaitRequest+0x60
82870c80 00000000 82890db8 VdsSftpMrx!NulMRxCloseSrvOpen+0x1b8
8254af60 82870c80 82936f68 VdsSftpMrx!RxCloseAssociatedSrvOpen+0x19f
82870c80 8218caa0 f15dfc88 VdsSftpMrx!RxCommonClose+0x229
f15dfc88 82936f02 82936fd8 VdsSftpMrx!RxFsdCommonDispatch+0x333
82060038 82936f02 00000001 VdsSftpMrx!RxFsdDispatch+0xd9
82060038 82936f68 82060038 VdsSftpMrx!NulMRxFsdDispatch+0x69
82936f78 82936f68 8218caa0 nt!IopfCallDriver+0x4f
801024a4 8218ca88 822dc980 nt!IovCallDriver+0x9e
0018caa0 00000000 8218ca88 nt!IopDeleteFile+0x151
8218caa0 00000000 8218ca88 nt!ObpRemoveObjectRoutine+0x1dc
e1022d58 81f154f0 00000a00 nt!ObfDereferenceObject+0x8c
e1022d58 00000000 00000a00 nt!ObpCloseHandleTableEntry+0x1f9
00000a00 00000001 00000000 nt!ObpCloseHandle+0xcc
00000a00 8010214f 00000000 nt!NtClose+0x1b

The address it was trying to access was 0x825c6e7c, which is
a KEVENT object, and appears perfectly valid (at least to my
unpracticed eyes):

0: kd> dt -b nt!_KEVENT 0x825c6e7c
+0x000 Header :
+0x000 Type : 0 ‘’
+0x001 Absolute : 0x5d ‘]’
+0x002 Size : 0x4 ‘’
+0x003 Inserted : 0x5d ‘]’
+0x004 SignalState : 0
+0x008 WaitListHead : [0x825c6e84 - 0x825c6e84]
+0x000 Flink : 0x825c6e84
+0x004 Blink : 0x825c6e84

The machine is running the checked ntoskrnl and hal from
XP sp1, with everything else from the free build.

I’m at a complete loss here; if anyone has any clues
what to look for, I’d appreciate a hint.

Thanks,

Joseph

2

You don’t mention the bug check - let me guess - IRQL_NOT_LESS_OR_EQUAL,
right?

Try using !pte on the address of the dispatcher object (“!pte
0x825c6e7c” in the example below) and I suspect that you will find the
page is in transition - in that case, the debugger will show you the
data contents (they ARE in memory) but it would still trigger a page
fault.

My guess is that you have a dispatcher object allocated from paged pool,
or placed in a paged data region of your driver.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Friday, August 13, 2004 1:36 PM
To: ntfsd redirect
Subject: [ntfsd] Puzzling crash @ high IRQL

I was doing some testing with my redirector and I got this crash
at high IRQL… the puzzling thing is, the IRQL is 0x1c, my driver
never raises IRQL, and the memory location it was accessing is valid
in the debugger.

This happened running under the driver verifier, with everything
except low resource turned on.

This is the stack trace (I omitted the ebp and retaddr
columns so it wouldn’t wrap in email):

00000000 00000000 00000000 nt!KeWaitForSingleObject+0xeb
825c6e7c 00000000 00000000 nt!VerifierKeWaitForSingleObject+0x54
820603f8 00000002 81f15500 VdsSftpMrx!WaitRequest+0x60
82870c80 00000000 82890db8 VdsSftpMrx!NulMRxCloseSrvOpen+0x1b8
8254af60 82870c80 82936f68 VdsSftpMrx!RxCloseAssociatedSrvOpen+0x19f
82870c80 8218caa0 f15dfc88 VdsSftpMrx!RxCommonClose+0x229
f15dfc88 82936f02 82936fd8 VdsSftpMrx!RxFsdCommonDispatch+0x333
82060038 82936f02 00000001 VdsSftpMrx!RxFsdDispatch+0xd9
82060038 82936f68 82060038 VdsSftpMrx!NulMRxFsdDispatch+0x69
82936f78 82936f68 8218caa0 nt!IopfCallDriver+0x4f
801024a4 8218ca88 822dc980 nt!IovCallDriver+0x9e
0018caa0 00000000 8218ca88 nt!IopDeleteFile+0x151
8218caa0 00000000 8218ca88 nt!ObpRemoveObjectRoutine+0x1dc
e1022d58 81f154f0 00000a00 nt!ObfDereferenceObject+0x8c
e1022d58 00000000 00000a00 nt!ObpCloseHandleTableEntry+0x1f9
00000a00 00000001 00000000 nt!ObpCloseHandle+0xcc
00000a00 8010214f 00000000 nt!NtClose+0x1b

The address it was trying to access was 0x825c6e7c, which is
a KEVENT object, and appears perfectly valid (at least to my
unpracticed eyes):

0: kd> dt -b nt!_KEVENT 0x825c6e7c
+0x000 Header :
+0x000 Type : 0 ‘’
+0x001 Absolute : 0x5d ‘]’
+0x002 Size : 0x4 ‘’
+0x003 Inserted : 0x5d ‘]’
+0x004 SignalState : 0
+0x008 WaitListHead : [0x825c6e84 - 0x825c6e84]
+0x000 Flink : 0x825c6e84
+0x004 Blink : 0x825c6e84

The machine is running the checked ntoskrnl and hal from
XP sp1, with everything else from the free build.

I’m at a complete loss here; if anyone has any clues
what to look for, I’d appreciate a hint.

Thanks,

Joseph

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

3

Tony Mason wrote:

You don’t mention the bug check - let me guess - IRQL_NOT_LESS_OR_EQUAL,
right?
>
Try using !pte on the address of the dispatcher object (“!pte
0x825c6e7c” in the example below) and I suspect that you will find the
page is in transition - in that case, the debugger will show you the
data contents (they ARE in memory) but it would still trigger a page
fault.

My guess is that you have a dispatcher object allocated from paged pool,
or placed in a paged data region of your driver.

You are correct.

Thanks for the debugging help; I’ll remember !pte for checking
the status of memory… and I’ll know not to assume it’s valid just
cause the debugger can read it.

Thanks,

Joseph