Hi,
Enabling Deadlock Detection in Driver Verifier causes a DRIVER_VERIFIER_DETECTED_VIOLATION (c4) when I run the code below:
void* objects = { &mutex, &shutDownEvent };
KWAIT_BLOCK wait_block[2];
NTSTATUS status;
status = KeWaitForMultipleObjects( 2, objects, WaitAny, Executive,
KernelMode, FALSE, NULL, wait_block );
if (status == 0) {
…
KeReleaseMutex( &mutex, FALSE ); <– BugCheck C4, {1007, 81c18fdc, ffadf618, 0}
} else if (status == 1)
// cleanup
} else {
// handle error
}
The 0x1007 code maps to the Deadlock Detection error:
“Unacquired resource: A resource is being released without having first been acquired.”
If I inspect the mutex with WinDbg it appears to have been acquired. If I disable Deadlock Detection from Driver Verifier everything seems to work just fine.
Is this a bug in Driver Verifier or am I using KeWaitForMultipleObjects incorrectly?
Thanks,
Carsten Schmidt
One mistake that you make is that you are call KeWaitForMultipleObjects not
specifying a pointer to a KWAIT_BLOCK but a KWAIT_BLOCK. I do not know how
mutex and shutDownEvent are declared but make sure you got the pointer
direction right on those also. Although they are not causing the problem,
instead of (status==0) or (status==1) you should use the STATUS_WAIT_0 and
STATUS_WAIT_1 constants.
/Daniel
wrote in message news:xxxxx@ntdev…
> Hi,
>
> Enabling Deadlock Detection in Driver Verifier causes a
> DRIVER_VERIFIER_DETECTED_VIOLATION (c4) when I run the code below:
>
>
> void* objects = { &mutex, &shutDownEvent };
> KWAIT_BLOCK wait_block[2];
> NTSTATUS status;
>
> status = KeWaitForMultipleObjects( 2, objects, WaitAny, Executive,
> KernelMode, FALSE, NULL, wait_block );
> if (status == 0) {
> …
> KeReleaseMutex( &mutex, FALSE ); <– BugCheck C4, {1007, 81c18fdc,
> ffadf618, 0}
> } else if (status == 1)
> // cleanup
> } else {
> // handle error
> }
>
>
> The 0x1007 code maps to the Deadlock Detection error:
> “Unacquired resource: A resource is being released without having first
> been acquired.”
>
> If I inspect the mutex with WinDbg it appears to have been acquired. If I
> disable Deadlock Detection from Driver Verifier everything seems to work
> just fine.
>
> Is this a bug in Driver Verifier or am I using KeWaitForMultipleObjects
> incorrectly?
>
> Thanks,
> Carsten Schmidt
>
>
he’s passing in the wait block array by name. this is equivalent to passing in a pointer to the array or a pointer to the first element of the array in.
-p
From: xxxxx@lists.osr.com on behalf of Daniel Terhell
Sent: Sat 10/7/2006 1:26 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Driver Verifier and KeWaitForMultipleObjects
One mistake that you make is that you are call KeWaitForMultipleObjects not
specifying a pointer to a KWAIT_BLOCK but a KWAIT_BLOCK. I do not know how
mutex and shutDownEvent are declared but make sure you got the pointer
direction right on those also. Although they are not causing the problem,
instead of (status==0) or (status==1) you should use the STATUS_WAIT_0 and
STATUS_WAIT_1 constants.
/Daniel
wrote in message news:xxxxx@ntdev…
> Hi,
>
> Enabling Deadlock Detection in Driver Verifier causes a
> DRIVER_VERIFIER_DETECTED_VIOLATION (c4) when I run the code below:
>
>
> void* objects = { &mutex, &shutDownEvent };
> KWAIT_BLOCK wait_block[2];
> NTSTATUS status;
>
> status = KeWaitForMultipleObjects( 2, objects, WaitAny, Executive,
> KernelMode, FALSE, NULL, wait_block );
> if (status == 0) {
> …
> KeReleaseMutex( &mutex, FALSE ); <– BugCheck C4, {1007, 81c18fdc,
> ffadf618, 0}
> } else if (status == 1)
> // cleanup
> } else {
> // handle error
> }
>
>
> The 0x1007 code maps to the Deadlock Detection error:
> “Unacquired resource: A resource is being released without having first
> been acquired.”
>
> If I inspect the mutex with WinDbg it appears to have been acquired. If I
> disable Deadlock Detection from Driver Verifier everything seems to work
> just fine.
>
> Is this a bug in Driver Verifier or am I using KeWaitForMultipleObjects
> incorrectly?
>
> Thanks,
> Carsten Schmidt
>
>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Re:[ntdev] Driver Verifier and KeWaitForMultipleObjectsSorry, you are right it is the name of an array so valid as a pointer so no invalid indirection so I started looking for some other problem. I noticed another thing, the doc says "If Count <= THREAD_WAIT_OBJECTS, then WaitBlockArray can be NULL. Otherwise this parameter must point to a memory buffer … " . THREAD_WAIT_OBJECTS is defined as 3 and he got 2 wait objects. In the way this piece of doc was written I got the strong idea that “can be NULL” should be interpreted like “must be NULL” because “can be NULL” does not explicitly refer to the case where count<=THREAD_WAIT_OBJECTS.
/Daniel
“Peter Wieland” wrote in message news:xxxxx@ntdev…
he’s passing in the wait block array by name. this is equivalent to passing in a pointer to the array or a pointer to the first element of the array in.
-p
------------------------------------------------------------------------------
From: xxxxx@lists.osr.com on behalf of Daniel Terhell
Sent: Sat 10/7/2006 1:26 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Driver Verifier and KeWaitForMultipleObjects
One mistake that you make is that you are call KeWaitForMultipleObjects not
specifying a pointer to a KWAIT_BLOCK but a KWAIT_BLOCK. I do not know how
mutex and shutDownEvent are declared but make sure you got the pointer
direction right on those also. Although they are not causing the problem,
instead of (status==0) or (status==1) you should use the STATUS_WAIT_0 and
STATUS_WAIT_1 constants.
/Daniel
wrote in message news:xxxxx@ntdev…
> Hi,
>
> Enabling Deadlock Detection in Driver Verifier causes a
> DRIVER_VERIFIER_DETECTED_VIOLATION (c4) when I run the code below:
>
>
> void* objects = { &mutex, &shutDownEvent };
> KWAIT_BLOCK wait_block[2];
> NTSTATUS status;
>
> status = KeWaitForMultipleObjects( 2, objects, WaitAny, Executive,
> KernelMode, FALSE, NULL, wait_block );
> if (status == 0) {
> …
> KeReleaseMutex( &mutex, FALSE ); <– BugCheck C4, {1007, 81c18fdc,
> ffadf618, 0}
> } else if (status == 1)
> // cleanup
> } else {
> // handle error
> }
>
>
> The 0x1007 code maps to the Deadlock Detection error:
> “Unacquired resource: A resource is being released without having first
> been acquired.”
>
> If I inspect the mutex with WinDbg it appears to have been acquired. If I
> disable Deadlock Detection from Driver Verifier everything seems to work
> just fine.
>
> Is this a bug in Driver Verifier or am I using KeWaitForMultipleObjects
> incorrectly?
>
> Thanks,
> Carsten Schmidt
>
>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
The WaitBlockArray parameter was originally NULL. I only added it to see if that would fix my problem, which it didn’t. Since the code works with Deadlock Detection disabled, i’m pretty sure that my object pointers are right.
I think the problem is that you try to release the mutex from a thread that didn’t acquire it.
DDK quote: A mutex object can be released only by the thread currently holding the mutex. If an attempt is made to release a mutex not held by the thread, a bug check occurs. An attempt to release a mutex object whose current state is signaled also causes a bug check to occur.
Eran.