Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Should a KernelMode KeWaitForSingleObject ever be Alterable?

osrdavid2osrdavid2 Member Posts: 1
edited November 2019 in NTDEV

Dear OSR,

I've been looking at what it means for a wait to be Altertable. I found these two helpful paragraphs: 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. 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

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,


Post edited by osrdavid2 on


  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,847

    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 Viscarola

  • anton_bassovanton_bassov Member Posts: 5,159

    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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA