Disk device restart fails with secure boot

Hi everyone, I have found a frustrating weird behavior that I cannot really figure out how to solve. I am working on a disk device filter driver that basically filters write requests and store them in a temporary location instead of letting them update underlying disk device.

Now, the design is pretty straightforward I believe. We use setup API to find device registry keys, add our driver as lowerfilter and then restart the disk device to attach it. This has worked perfectly on development virtual machines and several physical machines as well. When I now built a release driver and signed it and started trying it on production machines I found that it often fails to restart the disk device without a request for a reboot, which is surprising and does not make any sense, at least to me.

Setup log (using a virtual disk in this case, but it looks practically the same with for example an eSATA attached external disk too):

`>>> [Restart Device - SCSI\DISK&VEN_ARSENAL&PROD_VIRTUAL\1&1FBC229D&0&000100]

Section start 2019/05/23 13:09:57.911
cmd: “\vpcwin8ent.olofdom.se\users\olof.OLOFDOM\Source\Arsenal\ArsenalReconPrivate\ArsenalImageMounter\bin\Debug\ArsenalImageMounter.exe”
dvi: Device Status: 0x0180210a, Problem: 0x0 (0x00000000)
dvi: {Restarting Devices} 13:09:57.924
dvi: Needs Reinstall: SCSI\DISK&VEN_ARSENAL&PROD_VIRTUAL_\1&1FBC229D&0&000000
dvi: Needs Reinstall: USBSTOR\DISK&VEN_SANDISK&PROD_ULTRA&REV_1.00\4C530001240120109540&0
dvi: Needs Reinstall: SCSI\DISK&VEN_&PROD_ST9500420AS\4&2C493A39&0&040000
dvi: Needs Reinstall: SCSI\DISK&VEN_&PROD_ST98823AS\4&2C493A39&0&040000
dvi: Needs Reinstall: SCSI\DISK&VEN_MSFT&PROD_VIRTUAL_DISK\2&1F4ADFFE&0&000001
dvi: Needs Reinstall: SCSI\DISK&VEN_MSFT&PROD_VIRTUAL_DISK\2&1F4ADFFE&0&000002
dvi: Needs Reinstall: SCSI\DISK&VEN_MSFT&PROD_VIRTUAL_DISK\2&1F4ADFFE&0&000003
dvi: Query-remove: SCSI\DISK&VEN_ARSENAL&PROD_VIRTUAL\1&1FBC229D&0&000100
! dvi: Query-removal vetoed by ‘SCSI\Disk&Ven_Arsenal&Prod_Virtual\1&1fbc229d&0&000100t’ (veto type 5: PNP_VetoOutstandingOpen).
! dvi: Device required reboot: Query remove failed : 0x17: CR_REMOVE_VETOED.
dvi: Query-remove: SCSI\DISK&VEN_ARSENAL&PROD_VIRTUAL\1&1FBC229D&0&000000
! dvi: Query-removal vetoed by ‘STORAGE\Volume{0d2e8946-7b57-11e9-a3d1-844bf5641c35}#0000000000100000’ (veto type 6: PNP_VetoDevice).
! dvi: Device required reboot: Query remove failed : 0x17: CR_REMOVE_VETOED.
dvi: Query-remove: SCSI\DISK&VEN_INTEL&PROD_SSDSC2CW120A3\4&2C493A39&0&000000
! dvi: Query-removal vetoed by ‘SCSI\Disk&Ven_INTEL&Prod_SSDSC2CW120A3\4&2c493a39&0&000000000000100000’ (veto type 6: PNP_VetoDevice).
! dvi: Device required reboot: Query remove failed : 0x17: CR_REMOVE_VETOED.
dvi: Start: SCSI\DISK&VEN_ARSENAL&PROD_VIRTUAL\1&1FBC229D&0&000100
dvi: Start: SCSI\DISK&VEN_ARSENAL&PROD_VIRTUAL\1&1FBC229D&0&000000
dvi: Start: SCSI\DISK&VEN_INTEL&PROD_SSDSC2CW120A3\4&2C493A39&0&000000
dvi: {Restarting Devices exit} 13:10:04.423
<<< Section end 2019/05/23 13:10:04.429
<<< [Exit status: SUCCESS]
`

From how I interprete this log, there seems to be something open that vetoes the device restart. But this happens without even any file systems on the disk, even for completely blank not partitioned disks.

And, I have only seen this behavior when secure boot is active on the machine. I even tried now with a virtual machine where I have seen this problem constantly and disabled secure boot, rebooted and tried again and it all worked prefectly fine and the disk device was restarted as expected. Turning on secure boot again did not seem to bring the problem back again though, the disk devices I try this on can still be restarted with our filter driver attached even after turning secure boot back on and reboot.

Anyone have any clues? Have anyone seen anything similar? Any ideas at all?

Olof_Lagerkvist wrote:

! dvi: Query-removal vetoed by ‘SCSI\Disk&Ven_Arsenal&Prod_Virtual\1&1fbc229d&0&000100t’ (veto type 5: PNP_VetoOutstandingOpen).

Well, it says there is an outstanding open.  Do you have the Disk
Manager applet open?  Do you have an Explorer window open looking at
that disk?

Note: The email was trying to reply to an invalid Discussion (291348).

Thanks Tim, sorry for late response to this. We realize we draw the wrong conclusions here, the problem is indeed related to some open application that keeps a handle open. It actually seems to be Task Manager. This makes sense when it shows disk performance of course, I see the exact same behavior when I try to disable a disk in Device Manager with and without Task Manager open. With Task Manager open it requires a reboot, when closing Task Manager no reboot is required.

But this still surprised at least me a bit because in most cases when removing or restarting disks it is possible after having enumerated volumes for the disks and made sure they are dismounted. But of course that only helps if handles are opened for something that involves file systems. When handles are opened for the physical disk device object “\Device\000000xx” directly, which Task Manager seems to do, dismounting volumes will of course not help. I would have thought that applications that query performance values for disks would open “\?\PhysicalDriveX” objects, which are the “partition 0” objects which use RAW file system driver, but apparently they do not.