Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Handling WDM IRPs Outside of the Framework

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:

 

 

Send comments about this topic to Microsoft

Show:
© 2015 Microsoft