Driver Verifier doesn't seem to catch a WDF driver memory object leak

Question

So I'm suspecting a memory leak in a driver written with WDF. I've been trying to catch it with the driver verifier, but I can't seem to succeed.

I decided to test my approach. I wrote a small test driver, or more precisely, modified Microsoft's echo driver, and introduced a memory leak into it as such:

WDFMEMORY hMem = NULL;
Status = WdfMemoryCreate(WDF_NO_OBJECT_ATTRIBUTES, NonPagedPoolNx, 'aaaa', 1, &hMem, NULL);
if(Status == STATUS_SUCCESS)
{
 KdPrint(("WdfMemoryCreate leaked memory!\n"));
}
else
{
 KdPrint(("WdfMemoryCreate FAIL, status = 0x%X\n", Status));
}

After I load my echo.sys and enable driver verifier for it, and for the wdf01000.sys:

enter image description here

I also run the wdfverifier.exe and enable it for my echo.sys to track WDFMEMORY objects, among other things:

enter image description here

Then I run my echo driver with the code snippet above to introduce a memory leak. I can see the output in the DbgView, meaning that the leaky code had run.

I then tried to reboot the system while my echo.sys was still loaded, hoping to cause the verifier to catch my memory leak to emulate what I need the verifier to do in my actual driver. But nothing seem to happen, the OS just reboots.

I then tried to repeat the steps above, and then to unload manually my echo.sys with the memory leak in it. Still verifier fails to catch it. The driver simply unloads without a BSOD.

So what am I doing wrong?

• Luke: The documentation indicates that memory allocated via WdfMemoryCreate() is automatically freed by the framework when the parent object is deleted, in this case when the driver is unloaded: "The memory object and its buffer will be deleted when the parent object is deleted. If you do not change the default parent object, the memory object and its buffer will remain until the I/O manager unloads your driver."
• c00000fd: @Luke oh, you're right. My bad, I forgot to do WdfObjectReference(hMem). In that case, while unloading the driver the verifier causes the BSOD. I can't seem to find how to get the leaked memory tag though? !analyze -v in WinDbg doesn't seem to show much.
• Luke: Generally for a verifier BSOD the !analyze -v will give you some information on how to proceed further. I think generally you'll want to do something like !verifier 3 echo. Not sure if this is different in KMDF verifier as I don't really work with KMDF. If not perhaps there is a similar extension/command.
• c00000fd: @Luke yeah, for some reason I can't find any mentioning of my 'aaaa' tag anywhere. Also another thing that I mean to ask you. I get the BSOD if I manually unload my echo.sys. But if I reboot the OS no BSOD happens. What do you do (with the Verifier memory leak checks) if you can't unload the driver?
• Luke: Perhaps verifier doesn't do anything for a reboot since you're tearing down the entire system anyway; I don't recall what behavior is specified if any for reboots. Regardless, it seems wdfverifier is a bit different. I'm not familiar with it but this thread (and particularlly the linked comment) looks promising.