Dear OSR,
I’ve been looking at what it means for a wait to be Altertable. I found these two helpful paragraphs:
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/waits-and-apcs says:
Alerts, a seldom-used mechanism that are internal to the operating system,
can also interrupt alertable wait states. An alert can interrupt a wait when
Alertable = TRUE, regardless of the value of the WaitMode parameter.
The waiting routine returns a value of STATUS_ALERTED.
It is especially important to check the return value of KeWaitForSingleObject
when the WaitMode parameter is UserMode or Alertable is TRUE, because
KeWaitForSingleObject might return early with a status of STATUS_USER_APC
or STATUS_ALERTED.
I found a bug in our driver where it would call KeWaitForSingleObject
setting Alterable and then did not check for STATUS_ALERTED.
It was waiting on a KMUTEX then assuming it held the mutex whatever the
return code. When the return code was STATUS_ALERTED this assumption was false.
We’d get a mutex-released-when-not-held blue screen shortly after that of course!
The fix was simply not to set Alterable on the wait of course.
In the general case, are Altertable KernelMode KeWaitForSingleObject
calls that don’t check their return-code all bugs? I think so.
More generally, should a KernelMode KeWaitForSingleObject ever set Alterable?
I do not think it should. Is that correct?
If not, how is one supposed to process STATUS_ALERTED?
Thanks in advance,
David