Handling WDM IRPs Outside of the Framework
[Applies to KMDF only]
When the I/O manager delivers an I/O request packet (IRP) to a framework-based driver, the framework intercepts the IRP and then does one of the following:
Processes the IRP. For example, the framework processes IRPs that contain IRP_MJ_PNP and IRP_MJ_POWER major I/O function codes. While processing these IRPs, the framework might communicate with the driver by calling the driver's event callback functions.
Creates a framework request object for the IRP and delivers the request object to one of the driver's I/O queues so that the driver can receive it, typically in a request handler, and process it. The framework handles read, write, and device I/O control requests in this way.
Passes the IRP to the next-lower driver (if your driver is a filter driver), or completes the IRP with a status value of STATUS_INVALID_DEVICE_REQUEST (if your driver is not a filter driver) because the IRP contains an I/O function code that the framework does not support.
Sometimes a driver must handle an I/O function code that the framework does not support.
Rarely, a driver might need to preprocess an IRP before the framework handles it, or the driver might need to postprocess an IRP after the framework and lower-level drivers have finished processing it.
As part of preprocessing, a driver might need to forward an IRP to a specific I/O queue.
The following topics describe these situations:
- Handling an IRP that the Framework Does Not Support
- Preprocessing and Postprocessing IRPs
- Dispatching IRPs to I/O Queues