I am testing on a Win2k box, verifier enabled, /MAXMEM=64 and WinDbg
6.0.0007.0.
In one of my completion routines I need to make a couple of Rtl calls so I
check to determine if the IRQL == PASSIVE_LEVEL, if not I create a work item
to do the processing. Normally this works fine, however, I am receiving a
BSOD in the system thread handling my work item. Both !analyze -v and !pcr
show that the IRQL is DISPATCH_LEVEL(2).
Couple of questions, I know that in the past the IRQL level reported by
WinDbg could not be trusted. It was my understanding that this version of
WinDbg now correctly reports the IRQL, is this valid?
If so, then why would a system thread be running at DISPATCH_LEVEL? The
documentation specifically mentions that “callback is run within a system
thread context at IRQL PASSIVE_LEVEL.” Am I missing something here?
Thanks in advance.
Stanislaw
Ignore my last email, a spin lock was acquired in one of the routines
called, that explains the IRQL.
-----Original Message-----
From: Stanislaw Kowalczyk [mailto:xxxxx@relicore.com]
Sent: Tuesday, June 18, 2002 3:00 PM
To: NT Developers Interest List
Subject: Work items running at DISPATCH_LEVEL
I am testing on a Win2k box, verifier enabled, /MAXMEM=64 and WinDbg
6.0.0007.0.
In one of my completion routines I need to make a couple of Rtl calls so I
check to determine if the IRQL == PASSIVE_LEVEL, if not I create a work item
to do the processing. Normally this works fine, however, I am receiving a
BSOD in the system thread handling my work item. Both !analyze -v and !pcr
show that the IRQL is DISPATCH_LEVEL(2).
Couple of questions, I know that in the past the IRQL level reported by
WinDbg could not be trusted. It was my understanding that this version of
WinDbg now correctly reports the IRQL, is this valid?
If so, then why would a system thread be running at DISPATCH_LEVEL? The
documentation specifically mentions that “callback is run within a system
thread context at IRQL PASSIVE_LEVEL.” Am I missing something here?
Thanks in advance.
Stanislaw