Windows kernel mode programming: Is a deadlock between drivers possible?

Question

We're having some issues with our driver hanging while attempting to send a synchronous request to a lower level driver. The routine is currently being executed at DISPATCH_LEVEL when this routine is called.

I've been reviewing the Microsoft-supplied document "Locks, Deadlocks, and Synchronization" and it says the following:

Consider the case where code running at a low IRQL successfully acquires a lock, but the thread is interrupted to run code at a higher IRQL. If the higher-IRQL code tries to acquire the same lock, the thread may hang forever. The lower-IRQL code cannot run until the higher-IRQL code exits, but the higher-IRQL code cannot exit until the lower-IRQL code releases the lock. Only a single thread is involved. To prevent this problem, code that acquires a lock usually raises its IRQL to the highest IRQL at which any driver code that acquires the lock can run.

Our problem is giving us hangs and blue screens. While I understand that we aren't supposed to make calls that wait at DISPATCH_LEVEL and that our design needs work, I just want to make sure I understand the IRQL mechanism properly.

Am I correct that the IRQLs are per-processor, and that different drivers are going to run on different processors? I would like to confirm whether or not making a synchronous request targeted at the lower-level driver from DISPATCH_LEVEL is actually causing the problem by preempting the thread in the other driver due to its higher IRQL.

Answer 1

If you are doing a regular call, the other code will execute on the same CPU at the same level. If you are doing an async Send, then it may be scheduled on a different CPU. If you are doing a sync Send from a higher to a lower level driver, then you should probably be hanged. Just make it async and write the completion routine.