Handling an IRP that the Framework Does Not Support

[Applies to KMDF only]

The framework does not support I/O requests that have the following major IRP codes:

• IRP_MJ_CREATE_MAILSLOT
• IRP_MJ_CREATE_NAMED_PIPE
• IRP_MJ_DEVICE_CHANGE
• IRP_MJ_DIRECTORY_CONTROL
• IRP_MJ_FILE_SYSTEM_CONTROL
• IRP_MJ_FLUSH_BUFFERS
• IRP_MJ_LOCK_CONTROL
• IRP_MJ_QUERY_EA
• IRP_MJ_QUERY_INFORMATION
• IRP_MJ_QUERY_QUOTA
• IRP_MJ_QUERY_SECURITY
• IRP_MJ_QUERY_VOLUME_INFORMATION
• IRP_MJ_SET_EA
• IRP_MJ_SET_INFORMATION
• IRP_MJ_SET_QUOTA
• IRP_MJ_SET_SECURITY
• IRP_MJ_SET_VOLUME_INFORMATION

If the framework receives an IRP that contains one of these I/O function codes, the framework does not process the IRP. If your driver is a filter driver, the framework passes the IRP to the next-lower driver in the driver stack. If your driver is not a filter driver, the framework calls IoCompleteRequest to complete the IRP with a status value of STATUS_INVALID_DEVICE_REQUEST.

If your driver must handle IRPs that contain any of these I/O function codes, the driver must call WdfDeviceInitAssignWdmIrpPreprocessCallback to register an EvtDeviceWdmIrpPreprocess event callback function for an I/O function code.

When the driver receives an IRP that contains an I/O function code that the driver has registered an EvtDeviceWdmIrpPreprocess callback function for, the framework passes the IRP to the callback function. The callback function must then process the IRP by following the WDM rules for handling IRPs. The driver must call IoCompleteRequest to complete the IRP, or it must call IoCallDriver to pass the IRP to the next-lower driver.

For an example of an EvtDeviceWdmIrpPreprocess callback function that handles an IRP that the framework does not support, see the Serial sample driver.