Yeah, I would expect that the kernel will at times (or maybe always!)
access the object at DISPATCH or higher IRQL, which means that paged out
pages will not be available, and thus cause a page-fault, which causes a
BSOD.
Just allocate it from the non-paged pool and all will be fine.
Anything that may be used (read, written or executed) at DISPATCH level or
higher must be non-paged because the definition of DISPATCH level is that
you can’t switch thread. Since paging by definition requires another thread
to run (the “swapper” or “paging” thread in the kernel), you will not be
able to get whatever paged it.
The scary thing is that if you weren’t running DV, you’d probably be able
to run this code for a few days without failure, because in most cases, the
page will still be available when the kernel tries to access it, only once
in a blue moon will it be unavailable…
–
Mats
xxxxx@lists.osr.com wrote on 10/22/2004 11:53:12 AM:
Hi guys!
I’m solving a bugcheck on KeWaitForSingleObject for mutex allocated in
PagedPool.
KeWaitForSingleObject(&rwl->guard, Executive, KernelMode, FALSE, NULL);
(code is executing in a worker thread and i’m running the driver from
verifier)
As you can see I don’t specify “UserMode” as told in DDK documentation. I
searched a little and found the next article:
http://support.microsoft.com/kb/186775/en-us
It contains the next tip:
- Never allocate dispatcher objects from a paged pool. If you do, it
will
cause occasional system bugchecks.
Can anyone tell me is it true?
Vlad
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT00005ED2