How to cancel pending asynchronous request from Driver A to Driver B

NTDEV
1

Let’s say we have two kernel mode drivers namely Driver A(sender) and Driver B(receiver).
Driver A pends multiple asynchronous request to Driver B.
Now lets say Driver B(receiver) wants to unload, how do we handle cancellation of pending request that are not yet completed.
I am confused on following questions:

  1. Is there some code that needs to be implemented in Driver A(sender) that tells Driver B that “Hey, since you are planning to unload, why don’t you complete all the pending request with STATUS_CANCELLED”
  2. From what I Know, we need to implement EvtCancel callback routinen in Driver B, but I am not really sure what all infrastructure/WDF code changes are required to support this cancellation.
  3. Is there anything else that I need to be aware about when Driver B is going to unload?
2

Both KMDF and WDM have apis to cancel Irp’s that your driver created.
See WdfIoTargetPurge and IoCancelIrp.

Mark Roddy

3

You have several things backwards there. How would Driver A even know the Driver B was going to unload?

It is Driver B’s job to shut down the lines of communication and cancel whatever outstanding requests it still holds, by calling IoCancelIrp. And, assuming they are PnP drivers, that needs to be done long before it unloads. It is then Driver A that implements the EvtCancel callback, to catch the cancellation that was done by Driver B. The SENDER implements the cancel callback, not the RECEIVER.

4

If B is a pnp driver and A has an open file object/handle on B, A needs to register for file handle notifications (WDFIOTARGET makes this easy) so that they file can be closed and allow the query remove to succeed.

1 Like
5

How would Driver A even know the Driver B was going to unload?
I forgot to mention in the question, but Driver A subscribes to notification from Driver B. If Driver B wants to unload, Driver A gets that as a notification.
This is done by setting: EvtIoTargetQueryRemove callback.

Also, can’t Driver A directly call WdfIoTargetPurge with Driver B as its IoTarget. What are the disadvantage of using this method, I see that you mentioned two steps to do it. First by calling IoCancelIrp in Driver B and then implementing EvtCancel callback in Driver A

6

You have it flipped. Purge underneath the covers calls IoCancelIrp, this will invoke B’s EvtCancel

7

Sorry, I am confused.
Do you mean to say that we can’t invoke WdfIoTargetPurge(IoTargetDriverB, WdfIoTargetPurgeIo) from Driver A.
Based on what I read in the docs(if I read that correctly), using WdfIoTargetPurge would instruct Driver B to cancel all the pending IO’s from Driver A.
Correct if I am wrong.
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdfiotarget/nf-wdfiotarget-wdfiotargetpurge

8

Yes A calls Purge. For each sent request, it cancels each (IoCancelIrp). Canceling a request will invoke B’s EvtCancel.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.