IoVerifyVolume and VPB leak

NTDEV
1

In my testing it appears that IoVerifyVolume can leak the VPB of the passed device. This happens in either of these 2 cases:

  • The device has not been mounted before.
  • The device has been mounted before but the verification (IRP_MN_VERIFY_VOLUME) fails.

In either of these cases IoVerifyVolume attempts to (re-)mount the device. For this purpose it creates a new VPB using IopCreateVpb, but it does so without regard of whether a VPB exists already. IopCreateVpb appears to simply overwrite the DEVICE_OBJECT::Vpb field.

In my testing at least this appears to create a memory leak. Indeed if I modify my driver so that it frees that old VPB, the system chugs along without any complains about double frees or anything like that. (And yes, I always run my driver tests with verifier enabled).

This problem appears to exist in at least Win10 2004, but I believe it also exists in earlier and later versions of the OS.

Have I misunderstood IoVerifyVolume and how to use it?

Thank you.

2

@Bill_Zissimopoulos said:
In my testing it appears that IoVerifyVolume can leak the VPB of the passed device. This happens in either of these 2 cases:

  • The device has not been mounted before.

Normally the file system calls IoVerifyVolume as a result of the lower storage device failing an operation with STATUS_VERIFY_REQUIRED. Per the docs this shouldn’t happen if the device isn’t mounted (which makes sense…the point of verify is to detect swapping out one piece of media for another):

Ensure that the volume is mounted by checking the VPB_MOUNTED flag in the VPB. (If the volume is not mounted, the driver must not set the DO_VERIFY_VOLUME bit. The driver should set IoStatus.Status to STATUS_IO_DEVICE_ERROR, set IoStatus.Information to zero, and call IoCompleteRequest with the IRP.)

https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/notifying-the-file-system-of-possible-media-changes

  • The device has been mounted before but the verification (IRP_MN_VERIFY_VOLUME) fails.

FASTFAT says this in FatVerifyVolume:

If the volume verify fails, it may never be mounted again.  If it is
mounted again, it will happen as a remount operation.  In preparation
for that, and to leave the volume in a state that can be "lazy deleted"
the following operations are performed:

    - Set the Vcb condition to VcbNotMounted
    - Uninitialize the volume file cachemap
    - Tear down the allocation support

In the case of an abnormal termination we haven't determined the state of the volume, so we set the Device Object as needing verification again.

So, avoiding the call to IoVerifyVolume seems like the right call in this case.

3

Scott, thank you very much for your answer.

So, avoiding the call to IoVerifyVolume seems like the right call in this case.

I agree. I am not using IoVerifyVolume in my FSD because of this problem. Because I still need to force mounting at a certain point I now perform an IoCreateFileEx of the volume instead:

https://github.com/winfsp/winfsp/blob/v1.12B2/src/sys/volume.c#L118-L163

FYI, I have posted this as an issue against Microsoft’s DDI repo on GitHub:

https://github.com/MicrosoftDocs/windows-driver-docs-ddi/issues/1352

Thank you.

Bill