From: Alexander Grigoriev (alegr_at_earthlink.net)
Date: Wed, 14 Apr 2004 07:44:20 -0700
It's not obvious from the DDK docs. Actually I don't understand reason why
objects' array should be accessed while the thread is waiting. Addresses of
the objects are copied into the thread's array (or WaitBlockArray) of
KWAIT_BLOCK's, and there's no need to read the array again (unless an APC is
"Don Burn" <firstname.lastname@example.org> wrote in message
> You are correct you must allocate the WaitArray from NonPagedPool.
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
> "OttoVonRix" <OttoVonRix@iname.com> wrote in message
> > In my driver, a call to KeWaitForMultipleObjects is bugchecking:
> > if( KeWaitForMultipleObjects( NumObjs, pQuitObjects,
> > WaitAny, Executive,
> > FALSE,
> (PLARGE_INTEGER)&TimeOut, NULL ) != STATUS_TIMEOUT)
> > NumObjs in this case is 2. pQuitObjects is a dynamically allocated
> allocated with ExAllocPool, from the paged pool (an event and a thread).
> TimeOut is Zero
> > This code has been running for ages on many, many systems without
> problems. However, an MP Win2k machine has started bugcjecking. Here's
> I get:
> > 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: e27cb588, memory referenced
> > Arg2: 0000001c, IRQL
> > Arg3: 00000000, value 0 = read operation, 1 = write operation
> > Arg4: 8042becf, address which referenced memory
> > Debugging Details:
> > ------------------
> > READ_ADDRESS: e27cb588 Paged pool
> > CURRENT_IRQL: 1c
> > FAULTING_IP:
> > nt!KeWaitForMultipleObjects+99
> > 8042becf 8b38 mov edi,[eax]
> > This is on a Windows 2000 MP Kernel.
> > In the crash dump file, the read address (e27cb588) appears valid. This
> the address of the array of wait objects passed in to the function
> (allocated from the paged pool).
> > So, I guess I'm going to answer my own question: Is this problem caused
> allocating the array of wait objects (i.e. an array of pointers to
> kernel objects) from the paged pool?
> > The documentation doesn't explicitly state that this would be a problem?
> > With some overhead, I could change over to an on-stack array. With a
> KernelMode wait, would this be safe?
> > Thanks in advance!
> > Otto