Fixed Disks and Surprise Removal

SUMMARY

I have a Storport virtual miniport that creates fixed disks (i.e. non-removable and non-removable-media). On Windows 8 if I format the disk with NTFS or FAT and then surprise remove the disk, the file system does not dismount. Is this expected behavior or am I doing something wrong in my miniport?

DETAILS

I have a Storport virtual miniport that acts as a “proxy” to a user mode process. SCSI requests, such as READ, WRITE, SYNCHRONIZE CACHE and UNMAP are “forwarded” to user mode where they are handled. This works well and I am able to use diskpart to partition and format the “disk” and use the mounted file system (either NTFS or FAT).

Because the “disk” is served by a user mode process, I would like to gracefully handle sudden process termination. For this purpose I issue a BusChangeDetected upon process death and eliminate the dead LUN from my REPORT LUNS, INQUIRY, etc. messages. My understanding is that this should result in “Surprise Removal”, when the PNP manager discovers that the LUN is now gone.

Unfortunately this does not seem to be the case: the file systems do not seem to dismount. Looking at the FastFat code, the file system should dismount as a response to IRP_MN_SURPRISE_REMOVAL. However it appears that this IRP is never delivered: when I placed a breakpoint at FatPnpSurpriseRemove I never received it.

It should be noted that this appears to work well when I mark the disk as RemovableMedia during SCSI Inquiry. But I would think that “Surprise Removal” should work in the fixed disk case as well.

(This blog article suggests that in Windows 8.1 an event was added for this case, but the surprise removal happens in previous Windows versions (albeit unreported): https://blogs.msdn.microsoft.com/ntdebugging/2013/12/27/event-id-157-disk-has-been-surprise-removed/)

Yes your disappearing disks leave outstanding cached writes in limbo.
Generally you want to hide the removal from the file system, for example by
providing mirror paths and some sort of virtualized disk device. Otherwise
you need to not lie to the filesystem and let it know that your ‘disk’ can
go away, and then it will change its caching scheme and handle
disappearance corrtectly.

Mark Roddy

[I thought I have sent this, but found it somehow sitting in my Drafts folder.]

Mark, if I understand you correctly, you are effectively saying that this is just the way it is with fixed disks and that if I want the file systems to dismount I should mark the disks/media as removable.

Which is all fine and logical.

However it is my understanding that upon enumeration the PnP manager should find that the device is “missing” and should send a “Surprise Remove” regardless of whether the device is marked fixed or not. Is my understanding incorrect?

BTW, I have found that for some reason my miniport has a “RemovalPolicy” of 1 (RemovalPolicyExpectOrderlyRemoval). If I change this to 2 (RemovalPolicyExpectSurpriseRemoval) then the file system unmounts cleanly.

Bill_Zissimopoulos wrote:

However it is my understanding that upon enumeration the PnP manager should find that the device is “missing” and should send a “Surprise Remove” regardless of whether the device is marked fixed or not. Is my understanding incorrect?

Well, yes and no.  There are more players in the stack than just PnP. 
If your device is not marked as “removable”, then there are components
in the driver stack that will not expect it to be removed, and will not
play nicely if a remove request arrives… You get the same problem with
PCI devices.  There is hardware out there that allows PCI boards to be
hot-removed, but there are parts of the driver stack that just don’t
handle it.

Well, yes and no. There are more players in the stack than just PnP.

Tim, thank you for the additional explanation.