User request IRP cancellation

Is it fair to say that usermode-originated IRPs will not get a cancel request (cancel routine called) while they are in the dispatch routine in the calling thread context, and their cancel routine will always run in the originating thread context?

Neither assumption is correct. 2 counter reasons

  1. A filter can capture the irp, cancel it in another thread.
  2. The app dies and the io manager cancels io in all threads in another context

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Thursday, June 9, 2016 12:59 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] User request IRP cancellation

Is it fair to say that usermode-originated IRPs will not get a cancel request (cancel routine called) while they are in the dispatch routine in the calling thread context, and their cancel routine will always run in the originating thread context?


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

  1. For a top level driver, does it still hold?
  2. I believe the pending IRP list cancellation runs in the thread’s rundown path, which runs in the original thread context. The requests can still complete with non-zero return length, which will require an APC going back to the original thread.

My understanding is that you can only manage the thread’s IRP list reliably (without a cancel spinlock overhead) if you only add and remove IRPs to it in the thread context.

Then, there are IRPs that complete to an ICP (Io Completion Port, not Insane Clown Posse ;). Do they use an APC at all?

>1) A filter can capture the irp, cancel it in another thread.

Only the IRP creator can call IoCancelIrp.

Also, the “Canceling IRPs” WDK documentation page states that "If an IRP is not completed within 5 minutes, the I/O manager considers the IRP timed out. ". I suppose it’s the cancel timeout only.

In general yes, but what the docs are really saying is that if you can guarantee the lifetime of the PIRP when calling IoCancelIrp such that it doesn’t race by you in the completion path so you don’t touch freed memory, you can call IoCancelIrp in an intermediate driver and that is not the creator of the PIRP. KMDF allows you to do this.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Thursday, June 9, 2016 1:18 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] User request IRP cancellation

>1) A filter can capture the irp, cancel it in another thread.

Only the IRP creator can call IoCancelIrp.

Also, the “Canceling IRPs” WDK documentation page states that "If an IRP is not completed within 5 minutes, the I/O manager considers the IRP timed out. ". I suppose it’s the cancel timeout only.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

1 How can you guarantee you are the top level driver?
2 you are depending on current implementation, not the documented contract

What bigger problem are you trying to solve?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Thursday, June 9, 2016 1:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] User request IRP cancellation

1. For a top level driver, does it still hold?
2. I believe the pending IRP list cancellation runs in the thread’s rundown path, which runs in the original thread context. The requests can still complete with non-zero return length, which will require an APC going back to the original thread.

My understanding is that you can only manage the thread’s IRP list reliably (without a cancel spinlock overhead) if you only add and remove IRPs to it in the thread context.

Then, there are IRPs that complete to an ICP (Io Completion Port, not Insane Clown Posse ;). Do they use an APC at all?


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

From the WDK docs:

An intermediate driver should not arbitrarily call IoCancelIrp unless that driver created the IRP passed in the call. Otherwise, the intermediate driver might cancel an IRP that some higher-level driver is tracking for purposes of its own.

1 How can you guarantee you are the top level driver?

This is a control device object. It might have a DriverVerifier filter on top, but otherwise there is no reason to expect a weird ill-behaving upper filter.
In general, usermode IRPs have to arrive to the drivers who know how to handle them in the calling thread context and on PASSIVE_LEVEL, otherwise it’s impossible to support NEITHER I/O.

I’m trying to streamline my dispatch routines a bit. It’s a control device off NDIS miniport (created by NdisRegisterDeviceEx).