Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Reasons for volume teardown not completing

Alnoor_AllidinaAlnoor_Allidina Member Posts: 11


I'm helping out with an issue where a product caches data for each volume on the system. When a volume is torn down, the product cleans up its cached data. In some cases, when running alongside a particular backup application (they believe), volumes are occasionally not completely torn down and the product cache grows unwieldly.

I'm trying to understand why a particular volume has not fully dismounted.

What might I be missing or not understanding? Thanks in advance for any pointers.

Here's what I have deduced, given a manual dump that has my minifilter running in it.

  1. I see that my minifilter has seen the InstanceTeardownStartCallback but I see no evidence that it has seen InstanceTeardownComplete.
  2. I've searched the dump for any mention of the DiskDeviceObject in a an allocation with the 'File' pooltag, thinking there may be an open FILE_OBJECT. I found none.
  3. If I look at the DiskDeviceObject, I see that it's in remove pending state and the VPB has been mostly cleaned out:

    ##             0: kd> !devobj ffffe0015c24fca0
    ##         Device object (ffffe0015c24fca0) is for:
    ##          HarddiskVolume5 \Driver\volmgr DriverObject ffffe001537e13e0
    ##         Current Irp 00000000 RefCount 8 Type 00000007 Flags 00003050
    ##         Vpb ffffe0015a394120 SecurityDescriptor ffffc00077cae200 DevExt ffffe0015c24fdf0 DevObjExt ffffe0015c24ffa0 Dope ffffe0015aecbd90 DevNode ffffe00154c36d30 
    ##         ExtensionFlags (0x00000004)  DOE_REMOVE_PENDING
    ##         AttachedDevice (Upper) ffffe0015ca24310 \Driver\volsnap
    ##         Device queue is not busy.
    ##     0: kd> dt _VPB ffffe0015a394120 
    ##     ntdll!_VPB
    ##        +0x000 Type             : 0n10
    ##        +0x002 Size             : 0n96
    ##        +0x004 Flags            : 0x28
    ##        +0x006 VolumeLabelLength : 0
    ##        +0x008 DeviceObject     : (null) 
    ##        +0x010 RealDevice       : 0xffffe001`5c24fca0 _DEVICE_OBJECT
    ##        +0x018 SerialNumber     : 0xffffffff
    ##        +0x01c ReferenceCount   : 0
    ##        +0x020 VolumeLabel      : [32]  ""
  4. Here's what !fltkd says about the volume (there are a few open STREAM_LIST_CTRLs but no open contexts within them...) I'm attaching the verbose output as a file.

FLT_VOLUME: ffffe001587de7f0 "\Device\HarddiskVolume5"
FLT_OBJECT: ffffe001587de7f0 [04000000] Volume
RundownRef : 0x0000000000000006 (3)
PointerCount : 0x00000002
PrimaryLink : [ffffe00153dd0650-ffffe001542901a0]
Frame : ffffe00153dd0520 "Frame 0"
Flags : [00000164] SetupNotifyCalled EnableNameCaching FilterAttached +100!!
FileSystemType : [00000002] FLT_FSTYPE_NTFS
VolumeLink : [ffffe00153dd0650-ffffe001542901a0]
DeviceObject : ffffe0015679d3e0
DiskDeviceObject : ffffe0015c24fca0
FrameZeroVolume : ffffe001587de7f0
VolumeInNextFrame : 0000000000000000
Guid : "\??\Volume{75f14783-51e1-11ea-80f0-005056a67746}"
CDODeviceName : "\Ntfs"
CDODriverName : "\FileSystem\Ntfs"
TargetedOpenCount : 0
Callbacks : (ffffe001587de900)
ContextLock : (ffffe001587dece8)
VolumeContexts : (ffffe001587decf0) Count=1
StreamListCtrls : (ffffe001587decf8) rCount=9
FileListCtrls : (ffffe001587ded78) rCount=0
NameCacheCtrl : (ffffe001587dedf8)
InstanceList : (ffffe001587de880)
FLT_INSTANCE: ffffe0015bdbf010 "MpFilter Instance" "328000"
FLT_INSTANCE: ffffe0015c421010 "mfehidk" "321300.00"


Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 2 August 2021 Live, Online
Kernel Debugging 27 Sept 2021 Live, Online