Blue Moon, you saw me standing alone.....

I love sharing simple mistakes for some reason.  I think it's because we're all prone to searching for how to do something simple, like handle METHOD_NEITHER requests in our KMDF driver, and only read the documentation on how to initialize that ability, but not remembering all the little rules that govern the surrounding APIs.  Oft leaving us with a series of bug checks, driver load failures or head scratching "huh" scenarios.

This not so good -

     status = WdfDeviceCreate(&DeviceInit, &deviceAttributes, &device);
    if (!NT_SUCCESS(status)) 
    {
        KdPrint( ("WdfDeviceCreate failed with status code 0x%x\n", status));
        return status;
    }
    <...some other code went here...>
    WdfDeviceInitSetIoInCallerContextCallback (
        DeviceInit,
        SomeEvtInContextCallBack);

This good - 

     WdfDeviceInitSetIoInCallerContextCallback (
        DeviceInit,
        SomeEvtInContextCallBack);

    status = WdfDeviceCreate(&DeviceInit, &deviceAttributes, &device);
    if (!NT_SUCCESS(status)) 
    {
        KdPrint( ("WdfDeviceCreate failed with status code 0x%x\n", status));
        return status;
    }

 

See, at some point in history, I had paged out of my grey matter memory module that tidbit in the MSDN documentation for WdfDeviceCreate which says; After the driver calls WdfDeviceCreate, it can no longer access the WDFDEVICE_INIT structure.

Boy oh boy you sure can't access it afterwards, that bad boy is a glorious, awe inspiring, blue screening NULL after WdfDeviceCreate is through!