Fair enough, and this presents an excellent opportunity to get a definitive answer in the public record, so please make sure the court stenographer is recording this.
I have been waffling about this issue, and that waffling exposes a deep-seated and fundamental hole in my understanding of Windows. I have scanned literally dozens of articles in the past few days as this conversation has gone on, trying to find the definitive answer to a key question, and I find nothing in either MSDN or driver sources or this forum or the hallowed OSR NT Insider knowledge base that unambiguously answers it.
There are sources that clearly say that when a thread terminates, all of its outstanding I/O operations are canceled. Fair enough, you’d expect that. But I have never been able to find a source that definitively says the same thing happens when the last handle to a file object is closed. In fact, the evidence suggests the exact opposite: many conversations on this forum have cautioned “when a handle is closed, it is the responsibility of the driver to cancel any outstanding I/O requests.” The KMDF documentation clearly says that the framework cancels outstanding I/O operations when the handle is closed. The framework – not the kernel.
So, which is it? If pending IRPs are not automatically canceled on the last close, then a WDM driver must handle IRP_MJ_CLEANUP so it can do the cancellations. If not, the handle will never be closed. But if the I/O manager is automatically cancelling pending IRPs, then it is absolutely true that having an IRP cancel handler is sufficient.
I HOPE the latter is true. If so, then many documentation pages are wrong. They should not say “I/O operations are canceled when a thread terminates”. They should say “thread termination triggers a closing of all file handles, and closing a file handle triggers cancellation of outstanding I/O operations.” It would be nice to have a page that describes in detail the process of closing a file handle