According to the documentation here: https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/handling-device-power-down-irps
"The driver should queue any incoming I/O requests until the device has returned to the working state."
Ok. But let's assume this is the result of a PowerSystemShutdown, or a D3 cold IRP. Anything queued will be, well, lost. Because once I send the IRP down the stack, there's no coming back. Those devices will never accept writes.
I'm unable to find any documentation about whether its acceptable to fail IRPs or just drop them past a certain point. One thing I've noticed is that even after I've received a shutdown IRP there are often new IO requests still coming in (Easy test: start a non-quick format on a volume and then shutdown the system).
Presumably, there must be some "safe" cut-off point where a device cannot be reasonably expected to process IRPs, but I can't figure out if or where this is defined. I've followed the documentation to use PoSetPowerState, hoping that if I declare my upper level driver to be in powered off, then new IRPs will no longer be sent, but this assumption appears incorrect.
It's critical that my driver be the last writer to the device, but I can't find any way to ensure such a guarantee without setting HOLD_NEW_REQUESTS, marking irps pending (and then never really processing them), or failing them outright. How can I accomplish this?
Any help is much appreciated.
It looks like you're new here. If you want to get involved, click one of these buttons!
|Upcoming OSR Seminars|
|Developing Minifilters||29 July 2019||OSR Seminar Space|
|Writing WDF Drivers||23 Sept 2019||OSR Seminar Space|
|Kernel Debugging||21 Oct 2019||OSR Seminar Space|
|Internals & Software Drivers||18 Nov 2019||Dulles, VA|