Hi,
I am getting IOCTL (0x2d9194 - some system IOCTL) on my storage stack filter driver device object even after I have detached (IoDetachDevice) and deleted (IoDeleteDevice) it in IRP_MN_REMOVE_DEVICE. I am sure that IRP_MN_REMOVE_DEVICE has been processed before I am receiving this IOCTL by looking at my driver’s device extension member variables.
The device object has DOE_DELETE_PENDING flag set to it also.
0: kd> !devobj 0xfffffa81`047f2030
Device object (fffffa81047f2030) is for:
\Driver\Vtrack DriverObject fffffa806f9b33d0
Current Irp 00000000 RefCount 0 Type 00000007 Flags 00002010
Vpb fffffa810311e0b0 DevExt fffffa81047f2180 DevObjExt fffffa81047f3590
ExtensionFlags (0x00000012) DOE_DELETE_PENDING, DOE_START_PENDING
Characteristics (0000000000)
Device queue is not busy.
What does DOE_START_PENDING indicate here ?
It shows that device has been detached also. There is not AttachedTo (Lower) entry here.
The device object represents a filter device object on top of a cluster disk/volume.
Also, the !vpb shows its still having a reference to my driver’s device object (0xfffffa81047f2030)
0: kd> !vpb fffffa810311e0b0
Vpb at 0xfffffa810311e0b0
Flags: 0x8 (VPB_REMOVE_PENDING)
DeviceObject: 0x0000000000000000
RealDevice: 0xfffffa81047f2030
RefCount: 0
Volume Label:
Our driver is similar to FveVol in terms of its position in the storage stack. We have been able to safely delete our DO for regular disks. However, for this current issue at hand we have a cluster disk and it seems to me that FS is still mounted and is trying to issue some IOCTLs to storage stack when irp_mn_remove_device has already been handled.
*** Stack trace for last set context - .thread/.cxr resets it
Child-SP RetAddr Call Site
00 fffff8801583ee98 fffff88001faf14d nt!IofCallDriver+0x4b
01 fffff8801583eea0 fffff8800189cd75 VTrack!VtDispatchDeviceControl+0xced [d:\componentreleases\vtrack_11.0\ws\vtrack\dev\vtrack\vtioctl.cpp @ 1679]
02 fffff8801583ef50 fffff8000605cb67 Ntfs!NtfsStorageDriverCallout+0x16
03 fffff8801583ef80 fffff8000605cb2d nt!KxSwitchKernelStackCallout+0x27
04 fffff8801bda73a0 fffff800060b7ad8 nt!KiSwitchKernelStackContinue
05 fffff8801bda73c0 fffff800060ba405 nt!KeExpandKernelStackAndCalloutInternal+0x218
06 fffff8801bda74c0 fffff88001895f3d nt!KeExpandKernelStackAndCalloutEx+0x25
07 fffff8801bda7500 fffff880018bcc93 Ntfs!NtfsCallStorageDriver+0x31
08 fffff8801bda7560 fffff8800195ad96 Ntfs!NtfsNotifyVirtualDiskOfShutdownWorker+0xa7
09 fffff8801bda7600 fffff880019fd799 Ntfs!NtfsForEachVcb+0x1fe
0a fffff8801bda7690 fffff880016010ee Ntfs!NtfsFsdShutdown+0xd1
0b fffff8801bda7910 fffff88001f84991 fltmgr!FltpDispatch+0xee
0c fffff8801bda7970 fffff880016010ee VTrack!VtDispatchShutdown+0xd1 [d:\componentreleases\vtrack_11.0\ws\vtrack\dev\vtrack\vtrack.cpp @ 1743]
0d fffff8801bda79e0 fffff8000637696c fltmgr!FltpDispatch+0xee
0e fffff8801bda7a40 fffff80006376b12 nt!IopShutdownBaseFileSystems+0xbc
0f fffff8801bda7ac0 fffff80006379322 nt!IoShutdownSystem+0x122
10 fffff8801bda7b40 fffff800060a02a1 nt!PopGracefulShutdown+0x242
11 fffff8801bda7b80 fffff80006034fd9 nt!ExpWorkerThread+0x142
12 fffff8801bda7c10 fffff800060e97e6 nt!PspSystemThreadStartup+0x59
13 fffff8801bda7c60 0000000000000000 nt!KiStartSystemThread+0x16
The call stack suggests that we are getting call in frame # 1 through FS stack only. The crash is occurring in frame # 0 when we try to call lower level driver (DO) which has been detached already.
Any suggestions on why the FS stack is still sending IOCTLs to my device object when its already marked for delete_pending ? Is there a way for me not to pass on the IOCTL to lower device when I know that I have already detached from lower device in irp_mn_remove_device ?
Thanks,
Ukis