Hi all,
I have kernel thread which is using Guarded Mutexes for locking; thread starts on PASSIVE_LEVEL but KeGuardedMutexAcquire raises IRQL to APC and KeGuardedMutexRelease doesn’t lower it. Is it okay, after releasing the lock, to lower the IRQL back to PASSIVE_LEVEL so I can run some calls that require it (e.g. WdfDeviceStopIdle, or WdfQueueStopSynchronously)?
Thanks,
Maciej
Why not use Ex fast mutex instead?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hi all,
> I have kernel thread which is using Guarded Mutexes for locking; thread starts on PASSIVE_LEVEL but KeGuardedMutexAcquire raises IRQL to APC and KeGuardedMutexRelease doesn’t lower it. Is it okay, after releasing the lock, to lower the IRQL back to PASSIVE_LEVEL so I can run some calls that require it (e.g. WdfDeviceStopIdle, or WdfQueueStopSynchronously)?
>
> Thanks,
> Maciej
>
From my understanding both run @ APC, and starting from Win8 the implementation is the same anyway.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff545716(v=vs.85).aspx
>Is it okay, after releasing the lock, to lower the IRQL back to PASSIVE_LEVEL so I can run some >calls that require it (e.g. WdfDeviceStopIdle, or WdfQueueStopSynchronously)?
I would rise your thread to APC just before acquiring the mutex and explicitly restore your original IRQL after releasing the mutex.
Igor Sharovar
The only problem I see as a killer is, how do you know, beyond any doubt,
that you were at PASSIVE_LEVEL? At the very least, you should make sure
tgat’s where you’re starting. Now, if te Release osn’t reurning you to
PASSIVE_LEVEL, there are many possible explanations: (a) it is a deign
error; (b) it is a bug; (c) it is designed to work that way; (d) it is not
reasonable to return to PASSIVE_LEVEL due to strange and subtle
interactions which may lead to data corruption or BSOD. The scary problem
is the difference between (b) and (d). The suggestion made below simply
sidesteps the problem by avoiding it completely, a generally safer
approach than just slamming the IRQL.
“A superior programmer is someone who relies on his/her superior judgment
to avoid getting into sitations where his/her superior skill is needed”
(anyone who is a pilot will recognize where I ripped this off from).
joe
Why not use Ex fast mutex instead?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.comwrote in message news:xxxxx@ntdev…
>> Hi all,
>> I have kernel thread which is using Guarded Mutexes for locking; thread
>> starts on PASSIVE_LEVEL but KeGuardedMutexAcquire raises IRQL to APC and
>> KeGuardedMutexRelease doesn’t lower it. Is it okay, after releasing the
>> lock, to lower the IRQL back to PASSIVE_LEVEL so I can run some calls
>> that require it (e.g. WdfDeviceStopIdle, or WdfQueueStopSynchronously)?
>>
>> Thanks,
>> Maciej
>>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> if te Release osn’t reurning you to PASSIVE_LEVEL, there are many possible explanations:
(a) it is a deign error;
(b) it is a bug;
(c) it is designed to work that way;
(d) it is not reasonable to return to PASSIVE_LEVEL due to strange and subtle interactions which
may lead to data corruption or BSOD.
or, alternatively,
(e) it is a wrong evaluation of the situation by the OP, so that he is trying to solve the problem that, in actuality, does not exist.
I have a weird feeling that this scenario is the most likely one here…
Anton Bassov
You’re right; I should have included that; I didn’t think of it.
joe
> if te Release osn’t reurning you to PASSIVE_LEVEL, there are many
> possible explanations:>(a) it is a deign error;
> (b) it is a bug;
> (c) it is designed to work that way;
> (d) it is not reasonable to return to PASSIVE_LEVEL due to strange and
> subtle interactions which
> may lead to data corruption or BSOD.or, alternatively,
(e) it is a wrong evaluation of the situation by the OP, so that he is
trying to solve the problem that, in actuality, does not exist.I have a weird feeling that this scenario is the most likely one here…
Anton Bassov
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Whoops.
Seems like you guys were right about me being wrong. 
I had KeGuardedMutexRelease at the and of __try section instead of __finally in one place and that caused some anomalies.
Maciej