When you turn on the KMDF verifier(KMDFDV), a whole slew of behaviors are verified. Unlike the WDM driver verifier (DV) which allows you to select which behaviors to verify, KMDFDV is nearly an all or nothing affair. Future versions of KMDFDV will probably expose settings to enable selective verification. After KMDFDV has been enabled on your driver, certain debugger extensions in the wdfkd debugger extension can now give additional data. This document on WHDC describes each of the extension's commands. Enabling KMDFDV is not cheap, it can slow your driver down by as much as 50% (but DV also has the same affect).

Let's look at the output from !wdfkd.wdfdriverinfo, which I first presented in yesterday's post to get a better insight into what KMDFDV checks for.

1: kd> !wdfdriverinfo wdfrawbusenumtest fff
----------------------------------
Default driver image name:   wdfrawbusenumtest
[...]
----------------------------------
WDF Verifier settings for wdfrawbusenumtest.sys is ON
  Pool tracking is ON
  Handle verification is ON
  IO verification is ON
  Lock verification is ON

The list is pretty self explanatory from a top level POV. Let's go into some of the details of each setting:

  • Pool tracking: KMDF will track most (allocations that are near PAGE_SIZE or greater are not tracked) allocations made on behalf of the driver writer. You can see the tracking information by running !wdfpoolused on your driver.
  • Handle verification: KMDF will perform sanity checks on each KMDF handle passed to a KMDF DDI.
  • IO verification: KMDF will perform state and contract checks on WDFREQUESTs and WDFQUEUEs. For instance, you can only call WdfDeviceEnqueueRequest() within the context of your EvtIoInCallerContext() callback. Verifying that you are following the this rule in a production environment wastes cycles, so we only make the check when KMDF DV has been enabled.
  • Lock verification: This setting is the least relevant to a KMDF driver writer. When lock verification is enabled, each lock in KMDF is assigned a position in a locking hierarchy and upon each lock acquisition, KMDF verifies that the hierarchy has not been violated. Since you as the driver writer cannot create an entry into this hierarchy, there is no way for you to plug into this functionality.