IrpProcessing rule set (WDM)
Use these rules to verify that your driver correctly processes I/O request packets (IRP).
In this section
| Topic | Description |
|---|---|
The CompleteRequest rule verifies that the IoCompleteRequest routine is not called after a completion routine runs and that it does not return STATUS_MORE_PROCESSING_REQUIRED. |
|
The CompleteRequestStatusCheck rule verifies that the I/O status value in the IRP matches the status value returned by the lower driver. |
|
The CompletionRoutineRegistered rule specifies that if the dispatch routine registers an IoCompletion routine using IoSetCompletionRoutineEx, the dispatch routine must thereafter call IoCallDriver or PoCallDriver. |
|
The DoubleCompletion (WDM) rule specifies that the driver must not call the IoCompleteRequest routine twice for the same IRP. |
|
The IoReuseIrp rule specifies that a driver should use IoReuseIrp only on IRPs that it previously allocated with IoAllocateIrp. |
|
The IoReuseIrp2 rule specifies that a driver should use IoReuseIrp only on IRPs that it previously allocated within the driver. |
|
The IoSetCompletionExCompleteIrp rule specifies that the IoSetCompletionRoutineEx routine returns an NTSTATUS value. The driver must check this value to determine if the IoCompletion routine was successfully registered before calling IoCallDriver or PoCallDriver and if IoSetCompletionRoutineEx fails then the IRP should be completed and the dispatch routine should return. |
|
The IoSetCompletionRoutineExCheck rule specifies that the IoSetCompletionRoutineEx routine returns an NTSTATUS value. The driver must check this value to determine if the IoCompletion routine was successfully registered before calling IoCallDriver or PoCallDriver. |
|
The IoSetCompletionRoutineExCheckDeviceObject rule specifies that if the current device object is not passed to IoSetCompletionRoutineEx and the lower device object is, this can lead to a race condition where the current device object could be unloaded even though the completion routine has not run. |
|
The IoSetCompletionRoutineNonPnpDriver rule specifies that drivers that are not PnP drivers should use IoSetCompletionRoutineEx not IoSetCompletionRoutine. |
|
The IrpCancelField rule specifies that the driver check the value of the Irp->Cancel member when setting a cancel routine on an IRP that it has pended. |
|
The IrpProcessingComplete rule specifies that if a dispatch routine returns STATUS_SUCCESS, the IRP must have been completed by either the driver itself or by a lower-level driver. |
|
The LowerDriverReturn rule specifies that after using PoCallDriver or IoCallDriver to call a lower driver, the driver saves the return status from the call and passes the return status that it received to the dispatch routine. |
|
The SignalEventInCompletion rule specifies that when processing an asynchronous IRP, the driver needs to call the KeSetEvent in the completion routine when the Irp->PendingReturned flag is set. |
|
The SignalEventInCompletion2 rule specifies that when processing an asynchronous IRP, the driver needs to call the KeSetEvent in the completion routine when the Irp->PendingReturned flag is set. |
|
The SignalEventInCompletion3 rule specifies that when processing a asynchronous IRP, the driver needs to call the KeSetEvent in the completion routine when the Irp->PendingReturned flag is set. |
|
The StartIoCancel rule specifies that the driver must not call IoSetStartIoAttributes with the NonCancelable parameter set to FALSE before calling IoSetCancelRoutine with a non-NULLCancel routine. |
|
The StartIoRecursion rule specifies that if a driver's StartIo routine includes a call to IoStartNextPacket, the driver must first call IoSetStartIoAttributes with the DeferredStartIo attribute set to TRUE. Otherwise, infinite recursion can result. |
|
The PnpRemove rule specifies that the driver cannot complete IRP_MN_SURPRISE_REMOVAL, IRP_MN_CANCEL_REMOVE_DEVICE, IRP_MN_CANCEL_STOP_DEVICE, or IRP_MN_REMOVE_DEVICE requests with a failure. |
|
The PnpSurpriseRemove rule specifies that the driver does not call IoDeleteDevice or IoDetachDevice while processing an IRP_MN_SURPRISE_REMOVAL request. |
|
The PowerDownAllocate rule specifies that an FDO and FIDO driver should not allocate memory when processing an IRP_MN_SET_POWER request for a SystemPowerState transition that goes from s0 to [S1...S5]. |
|
The PowerDownFail rule specifies that a FDO or FIDO driver should not fail an IRP_MN_SET_POWER request when the device is powering down. This rule only applies to FDO and FIDO drivers. |
|
The PowerIrpDDIs rule specifies that when a driver is processing a system or a device IRP_MJ_POWER with IRP_MN_SET_POWER, it should not call DDIs that can only be call at PASSIVE_LEVEL. |
|
The PowerUpFail rule specifies a FDO or FIDO driver should not fail a IRP_MN_SET_POWER request when the device is powering up. |
|
The PnpIrpCompletion rule verifies that an FDO driver passes PnP IRPs to the lower driver. |
|
The WmiComplete rule specifies that when processing a WMI minor IRP, the driver calls IoCompleteRequest before returning from the DispatchSystemControl routine. |
|
The WmiForward rule specifies that the driver must forward WMI minor IRPs when forwarding is required. |
To select the IrpProcessing rule set
Select your driver project (.vcxProj) in Microsoft Visual Studio. From the Driver menu, click Launch Static Driver Verifier….
Click the Rules tab. Under Rule Sets, select IrpProcessing.
To select the default rule set from a Visual Studio developer command prompt window, specify IrpProcessing.sdv with the /check option. For example:
msbuild /t:sdv /p:Inputs="/check:IrpProcessing.sdv" mydriver.VcxProj /p:Configuration="Win8 Release" /p:Platform=Win32For more information, see Using Static Driver Verifier to Find Defects in Drivers and Static Driver Verifier commands (MSBuild).
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for