We have a File System (not a filter) which has supported driver
unload for many years now, but with Windows 8.1 we seem to be
seeing intermittent driver unload failures. I suspect the
problem is possible on other versions of Windows, perhaps all,
but that’s just a guess.
This condition caused me to question my understanding of what
is necessary to get a File System driver to unload (and in
particular whether it is different than other drivers).
My current understanding would lead me to believe that the state
of the device and driver options from the windbg output below
indicates that the driver is be in a state to unload but I’m
suspecting I have something new to learn here and we’ve just
been lucky that this has worked up to now.
So my question is whether anything in the state of the device
object or driver object below indicate a reason for the driver
to not unload. The only references that are non-zero
are the “generic object” (PointerCount) references, but the
device object ReferenceCount is zero (and that together with
DOE_UNLOAD_PENDING|DOE_DELETE_PENDING being set I thought was
enough to cause my “DriverUnload” handler to be called, but
that is not occurring).
=================================================================
0: kd> !devobj 0xffffe00000a45bd0
Device object (ffffe00000a45bd0) is for:
cvfs \FileSystem\Cvfs DriverObject ffffe00003d0ee60
Current Irp 00000000 RefCount 0 Type 00000008 Flags 00000040
Dacl ffffc101001aeed0 DevExt ffffe00000a45d20 DevObjExt ffffe00000a45f98
ExtensionFlags (0x00000803) DOE_UNLOAD_PENDING, DOE_DELETE_PENDING,
DOE_DEFAULT_SD_PRESENT
Characteristics (0000000000)
Device queue is not busy.
0: kd> !object 0xffffe00000a45bd0
Object: ffffe00000a45bd0 Type: (ffffe000001bac60) Device
ObjectHeader: ffffe00000a45ba0 (new version)
HandleCount: 0 PointerCount: 1
Directory Object: 00000000 Name: cvfs
0: kd> !drvobj ffffe00003d0ee60
Driver object (ffffe00003d0ee60) is for:
\FileSystem\Cvfs
Driver Extension List: (id , addr)
Device Object list:
ffffe00000a45bd0
0: kd> !object ffffe00003d0ee60
Object: ffffe00003d0ee60 Type: (ffffe000001bab00) Driver
ObjectHeader: ffffe00003d0ee30 (new version)
HandleCount: 0 PointerCount: 3
Directory Object: ffffc0000007b2e0 Name: Cvfs
0: kd> dt DEVICE_OBJECT 0xffffe00000a45bd0
cvfs!DEVICE_OBJECT
+0x000 Type : 0n3
+0x002 Size : 0x3c8
+0x004 ReferenceCount : 0n0
+0x008 DriverObject : 0xffffe00003d0ee60 _DRIVER_OBJECT +0x010 NextDevice : (null) +0x018 AttachedDevice : (null) +0x020 CurrentIrp : (null) +0x028 Timer : (null) +0x030 Flags : 0x40 +0x034 Characteristics : 0 +0x038 Vpb : (null) +0x040 DeviceExtension : 0xffffe000
00a45d20 Void
+0x048 DeviceType : 8
+0x04c StackSize : 1 ‘’
+0x050 Queue :
+0x098 AlignmentRequirement : 0
+0x0a0 DeviceQueue : _KDEVICE_QUEUE
+0x0c8 Dpc : _KDPC
+0x108 ActiveThreadCount : 0
+0x110 SecurityDescriptor : 0xffffc0000008ee30 Void<br> +0x118 DeviceLock : _KEVENT<br> +0x130 SectorSize : 0x200<br> +0x132 Spare1 : 1<br> +0x138 DeviceObjectExtension : 0xffffe000
00a45f98 _DEVOBJ_EXTENSION
+0x140 Reserved : (null)
0: kd> dt DRIVER_OBJECT 0xffffe00003d0ee60<br>cvfs!DRIVER_OBJECT<br> +0x000 Type : 0n4<br> +0x002 Size : 0n336<br> +0x008 DeviceObject : 0xffffe000
00a45bd0 _DEVICE_OBJECT
+0x010 Flags : 0x92
+0x018 DriverStart : 0xfffff80003a00000 Void<br> +0x020 DriverSize : 0x29a9000<br> +0x028 DriverSection : 0xffffe000
01bdc120 Void
+0x030 DriverExtension : 0xffffe00003d0efb0 _DRIVER_EXTENSION<br> +0x038 DriverName : _UNICODE_STRING "\FileSystem\Cvfs"<br> +0x048 HardwareDatabase : 0xfffff801
92722580 _UNICODE_STRING
“\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM”
+0x050 FastIoDispatch : 0xfffff8000639a578 _FAST_IO_DISPATCH<br> +0x058 DriverInit : 0xfffff800
063a3064 long
cvfs!GsDriverEntry+0
+0x060 DriverStartIo : (null)
+0x068 DriverUnload : 0xfffff80003b04590 void<br> cvfs!CvNtDriverUnload+0<br> +0x070 MajorFunction : [28] 0xfffff800
03b144d0 long
cvfs!CvCreateDispatch+0
=================================================================
Assuming the above indicates the device/driver objects are in the
right state to unload, perhaps the following is relevant.
Traces indicate this problem occurs when we get an IRP_MN_MOUNT_VOLUME
call from Windows (in this case for a partition that is not ours so
we just return STATUS_UNRECOGNIZED_VOLUME) when we are in the middle
of the unload process (in particular, we are in the middle of a CLOSE
dispatch which has called IoUnregisterFileSystem, which I suspect is
the key to getting out of the file system lists that result in the
IRP_MN_MOUNT_VOLUME queries).
One of the possible issues here is that our driver should be doing
some operation that causes these IRP_MN_MOUNT_VOLUME requests to
quiesce, but I am unaware of any such mechanism. The ReferenceCount
on the device object at the time of the IRP_MN_MOUNT_VOLUME appears
to be 2 and I’m suspecting that the decrement of ReferenceCount to
zero is in the thread issuing the IRP_MN_MOUNT_VOLUME but I could be
wrong about that.
Thanks,
Eric