SDV and verifier different results for IoSetCompletionRoutine / KeWaitForSingleObject

Static Driver Verifier reports 2xWARNING StartDeviceWait and StartDeviceWait3 whilst Verifier.exe runs the test and passes without any errors or warning.

In an DispatchPnp IRP_MN_START_DEVICE routine you do the typical send the IRP down synchronously (KeInitializeEvent, IoCopyCurrentIrpStackLocationToNext, IoSetCompletionRoutine, IoCallDriver) and wait for the lower device, and complete the request. With the event waiting on STATUS_PENDING recommended by MSDN.

    KeInitializeEvent(&event, NotificationEvent, FALSE);
    IoCopyCurrentIrpStackLocationToNext(Irp);
    IoSetCompletionRoutine(Irp, SendIrpSyncCompletionRoutine, &event, TRUE, TRUE, TRUE);
    status = IoCallDriver(TargetDeviceObject, Irp);
    if (status == STATUS_PENDING)
    {
        KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL); // SDV doesn't like this inside IRP_MN_START_DEVICE 
        status = Irp->IoStatus.Status;
    }
    return status;

However this runs all fine and dandy, and even verifier.exe enabled with [X] (0x00000010) I/O verification and [X] (0x00000200) Force pending I/O requests we can see in WinDbg !verifier 40, all the “pending” I/O requests that are thrown are fine, and I see all the relevant dbgprints in the completion routine/status_pending statements which never hit apart from in these tests.

So which is correct? SDV or Verifier? And how does one resolve the SDV warnings, since most driver code related to this I’ve checked online all do it this way, even MSDN docs say this is the recommended method

It’s been soooo long (ten years now, probably) since I’ve thought about this… you know, this is why KMDF was invented.

IIRC, best practice is not to block in order to facilitate faster system startup. This is certainly the case with Power IRPs, and ISTR this is true of PnP as well.

BTW, “which is right” when it comes to Verifier and SDV is unusually not the right question. Verifier’s intent is to (for almost all categories) only report things that are unambiguously errors… Verifier seeks to eliminate false positives. Now, we all may have cases where we respectfully beg to differ about a given rule or architectural precept that Verifier implements… but it’s rulings reflect the MSFT view of the world.

SDV, on the other hand, is a different tool for a different job. It’s remit is much broader, and is designed to keep drivers out of trouble and (where possible) conformant with best practices.

They should be viewed as complementary, not necessarily overlapping, tools.

Peter