Trouble Understanding Behaviour at IRQL=DISPATCH_LEVEL

NTDEV
1

I was reading through Windows NT Driver Development by Peter

and came to the following text

The effect of disabling dispatching when running at IRQL DISPATCH_LEVEL can be seen in the following example. We recently heard from one unfortunate driver writer who wanted to understand why his call to KeWaitForSingleObj ect () returned STATUS_SUCCESS , even though the event was never signaled. After some discussion, we learned that this call was being made from a Deferred Procedure Call (DPC) in the context of the system idle thread (DPCs are discussed in detail in Chapter 1 5, "Interrupt Service Routines and DPCs "). The call to KeWaitForSingleObject( ) called the dispatch code. The dispatch code determined that there were no threads to run, so it would explicitly choose to run the system idle thread. The dispatcher thus returned STATUS_SUCCESS , so ultimately KeWaitForSingleObject() also returned STATUS_SUCCESS , even though the event was not signaled. All we could say was "Yikes! "

What may be less obvious is that when code is executing at IRQL DISPATCH_LEVEL or above, it cannot wait for any Dispatcher Objects that are not already signaled. Thus, for example, code running at IRQL DISPATCH_LEVEL or above cannot wait for an event or mutex to be set. This is because the act of yielding the processor requires (at least conceptually) the Dispatcher to run. However, if a routine is running at or above DISPATCH_LEVEL , the DISPATCH_LEVEL interrupt will be masked off and therefore not immediately recognized. The result? A return directly back to the code that issued the wait operation!

What I am not getting here, is why does it the code returns ? shouldn’t it sleep forever or hang ? because the dispatcher isn’t running so no one will move our thread from Waiting to Running again ? perhaps on a uni-processor it will be a full-system hang ?, Also assuming that the system doesn’t bugcheck when doing that.

2

The text is very clear.
What may be less obvious is that when code is executing at IRQL DISPATCH_LEVEL or above, it cannot wait for any Dispatcher Objects that are not already signaled.

A few must says.
In DISPATCH_LEVEL, scheduler is effectively disabled. So you cannot just wait for a object. You can, however, acquire spinlocks. What matters more is that you are not allowed to stay on high IRQLs for too long.

Why it does return?
KeWaitForSingleObject calls the dispatcher (scheduler) to make a wait on the object you specified. Since the dispatcher interrupt is masked off at DISPATCH_LEVEL, as I stated above, the call is never made. So the current thread isn't put on wait list, and KeWaitForSingleObject returns immediately, since the code continues to run instead of being put to wait by scheduler.

4

@Staarblitz

I understand that the dispatcher interrupt is disabled, however KeWaitForSingleObject still calls the disptacher functions, like KiSwapThread, it also appends the thread to the waiting list.

I think it returned in the first case because we were in the context of idle system thread, however I am not sure about the second case .

5

Why don't you step over it and see why? Since you seem too curious on what it internally does.