DriverVerifier assert, common buffer's not freed

Hi Everyone,

Working on a miniport driver here and I’ve run into an interesting driver verifier assert that I can’t seem to put my finger on. A little history:

I have a top level bus driver which breaks out 4 devices which I then attach a separate miniport driver to. Each of these devices has its own dedicated memory region corresponding to 4 ports on the PCI card. The miniport driver registers for scatter gather dma and then on the receive side uses NdisMAllocateSharedMemory to allocate buffer descriptors. This all works fine.

With driver verifier turned on with the standard settings, I get the following when I attempt to disable any of my miniport devices.

*** Verifier assertion failed ***
(B)reak, (I)gnore, (W)arn only, (R)emove assert? I
I
**************** HAL Verifier Detected Violation ****************
**
** VF: Cannot put adapter FFFFB40DEA425DD0 until all common buffers are freed (303 left).
**
*****************************************************************

What’s interesting here is that if I disable another miniport device (without re-enabling the other one I just disabled) The count on the common buffers freed decrements. and looks like this:

*** Verifier assertion failed ***
(B)reak, (I)gnore, (W)arn only, (R)emove assert? I
I
**************** HAL Verifier Detected Violation ****************
**
** VF: Cannot put adapter FFFFB40DEA425DD0 until all common buffers are freed (202 left).
**
*****************************************************************

I can remove another one and get a similar decrement, but when I remove the last miniport device I don’t get an assert.

I’ve gone through my code meticulously and I am freeing everything that I allocate as the driver halts. I’m pretty confident at this point that i’m not leaving any memory open. It appears to me that the driver verifier might be picking up on the remaining allocated dma memory from the other miniport devices that are still running. Is this possible? If so am I potentially missing something in how a bus driver creates a child pdo which would be causing some kind of memory association? Grasping at straws a bit here and I’m looking to see if someone might know a bit more than I on this subject.

I’m open to posting some code snippets here, but wanted to get the ball rolling as I’m not sure at this point what will be valuable.

Thanks in advance!

Posting a solution here for future reference just in case someone else finds themselves in this obscure corner case.

My initial suspicion that our custom bus driver was somehow associating the dma memory with the other miniport devices was a good hunch. After going through my code for a couple of days I realized that I had a logic error in my bus driver which was preventing me from setting up and calling the WdfDeviceSetBusInformationForChildren function. I’m still not entirely sure what is happening behind the scenes here, but I can tell you that once I start calling that function the problem described above disappears entirely. My guess is that, and someone that’s more in the know please pipe in if i’m wrong, by not calling the WdfDeviceSetBusInformationForChildren function my children were not correctly being associated with their parent bus driver, this was causing the the driver verifier tool to see the memory allocated by the chidren (miniport) devices as if it was allocated by a single driver. Therefore when I would disable one of my four miniport drivers, it would look like I only freed 1/4 of the device. Then I would get a complaint from driver verifier telling me as much.