Should a KernelMode KeWaitForSingleObject ever be Alterable?

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.

https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-kewaitforsingleobject says:

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

Correct. Especially given that most kernel-mode processing is done in an arbitrary process/thread context, and kernel-mode APCs are not documented (in terms of building, queuing and executing them for a driver), it is almost always an error to wait alertable (or in UserMode for that matter) in a driver.

Peter

In the general case, are Altertable KernelMode KeWaitForSingleObject calls that don’t check their return-code all bugs?

Well, it depends on the parameters to KeWaitForSingleObject() . If they allow this call to return without the wait having had been actually satisfied, then assuming the successful wait completion is a very obvious bug that may have its “consequences”, as you have already experimentally established .

BTW, as long as you are sure that your code does not attempts to acquire the target mutex recursively you may want to try FAST_MUTEX instead of the “regular” one. Locking this construct involves raising IRQL to APC_LEVEL behind the scenes, so that the alerts are simply a non-issue.

More generally, should a KernelMode KeWaitForSingleObject ever set Alterable?

Well, it depends…

As long as you are 100% sure you are in context of the requesting application’s thread, you may,indeed, want to use the alertable wait, especially if your wait is infinite and unbounded (for example, you are waiting for the event that may or may not occur).
Otherwise, it is going to be impossible to terminate the requesting app until the wait is satisfied, and this is, probably, not what you want to happen. OTOH, you may structure your code is such a way that the need for the alertable wait never arises, in the first place. For example, you can pend the request and process it asynchronously when the event of interest occurs instead of waiting on notification events, and use FAST_MUTEX for synchronisation…

If not, how is one supposed to process STATUS_ALERTED?

Well, just keep in mind that the event you are waiting for has not occurred. It is up to you how to handle the situation , but repeating the wait seems to be the most obvious solution,don’t you think…

Anton Bassov