Warning rule set (KMDF)
Use these rules to verify that your driver can correctly processes IRPs in various contexts and follows Microsoft recommended best practices.
In this section
| Topic | Description |
|---|---|
The DeferredRequestCompleted rule specifies that if an I/O request presented to a driver's default I/O queue is not completed in the callback function but is deferred for later processing, the request must be completed in a deferred processing callback function, unless the request is forwarded and delivered to the framework, or unless the WdfRequestStopAcknowledge method is called. |
|
The DriverAttributeChanged rule specifies that a driver must not change the execution level or synchronization scope of a KMDF driver. |
|
The DrvAckIoStop rule verifies that the driver is aware of pending requests while its power-managed queue is getting powered-down and the driver acknowledges, completes, or cancels the pending requests accordingly. In the case of self-managed I/O requests, the driver should also correctly handle these requests from its EvtDeviceSelfManagedIoSuspend function. A driver that fails to handle these requests during a power-down would cause Bug Check 0x9F: DRIVER_POWER_STATE_FAILURE. |
|
The EvtIoResumeGetParam rule specifies that WdfRequestGetParameters is not called within the EvtIoResumeGetParam callback function. |
|
The EvtIoStopGetParam rule checks that WdfRequestGetParameters is not called within EvtIoStop callback. |
|
The EvtIoStopResume rule specifies that if a driver registers a EvtIoStop callback function and then calls WdfRequestStopAcknowledge with the Requeue parameter equal to FALSE, the driver must register a EvtIoResume callback function. The framework delivers requests to the EvtIoResume callback function when the device enters the D0 state again. |
|
The EvtSurpriseRemoveNoRequestComplete rule specifies that WDF drivers shouldn’t complete requests from EvtDeviceSurpriseRemoval callback, instead self-managed I/O callback functions should be used. EvtDeviceSurpriseRemoval callback isn’t synchronized with the power-down path. |
|
The FDOPowerPolicyOwnerAPI rule specifies that if an FDO driver relinquishes power policy ownership, the methods WdfDeviceInitSetPowerPolicyEventCallbacks, WdfDeviceAssignS0IdleSettings, and WdfDeviceAssignSxWakeSettings can only be called on the execution paths where the driver is a power policy owner. SDV issues a warning for this rule. |
|
The NoCancelFromEvtSurpriseRemove rule specifies that WDF Drivers shouldn’t cancel requests from the EvtDeviceSurpriseRemoval callback function, instead self-managed I/O callback functions should be used. EvtDeviceSurpriseRemoval callback function isn’t synchronized with the power-down path. |
|
The PagedCodeAtD0 rule specifies that a driver must not mark code as pageable within callback functions that are in the power-up code path. |
|
The ParentObjectCheck rule specifies that driver should call WdfMemoryCreate specifying a parent object using a WDF_OBJECT_ATTRIBUTES structure. If driver doesn’t set a parent object for the framework memory object then the framework sets the driver as the default parent, so that unless the driver deletes the framework memory object explicitly it’ll remain in the memory until the driver object unloads. |
|
The ReqNotCanceledLocal rule specifies that if a request marked as cancelable is completed in a default I/O queue callback function, the WdfRequestUnmarkCancelable method must be called on the I/O request before completion. The I/O request must be completed, unless the request is canceled before it calls WdfRequestUnmarkCancelable. |
|
The ReqSendFail rule specifies that a driver must set the correct completion status in cases in which the WdfRequestSend method might fail. |
|
The RequestCompletedLocal rule specifies that if an I/O request is not completed in any of the EvtIoDefault, EvtIoRead, EvtIoWrite, EvtIoDeviceControl, and EvtIoInternalDeviceControl callback functions, and if WdfRequestMarkCancelable was not called on the request within the callback function, there might be a problem with request completion in the driver's code. |
|
If the client driver calls WdfUsbTargetDeviceCreateWithParameters and specifies the client contract version USBD_CLIENT_CONTRACT_VERSION_602 in the WDF_USB_DEVICE_CREATE_CONFIG structure (to use the new capabilities of the USB driver stack for Windows 8), DDIs that use a URB internally would only use URB context if any of the following preconditions apply: |
|
The SyncReqSend rule specifies that all synchronous send requests are done by using synchronous-specific KMDF device driver interface methods, and that the methods have a nonzero timeout value set. |
|
The SyncReqSend2 rule specifies that synchronous request sends have a nonzero time-out value set. |
To select the Warning 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 Warning.
To select the default rule set from a Visual Studio developer command prompt window, specify Warning.sdv with the /check option. For example:
msbuild /t:sdv /p:Inputs="/check:Warning.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).