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:
I am not sure what’s going on here. Any pointers in this direction would be helpful.
Thanks,
Ukis
You’d be better served by asking in NTDEV where the lower storage folks tend to hang out, but my recollection is that storage stack filters aren’t supposed to delete their device objects (or there’s some complexity in this area).
Tony
OSR
>recollection is that storage stack filters aren’t supposed to delete their device objects (or there’s
some complexity in this area).
Surely the storage stack filter DOs are deleted, for instance, FveVol (BitLocker) and VolSnap.
The complexity is that it is very hard to delete the non-PnP block storage DO itself in a proper way, with the FS mounted on it. But again PnP helps a lot here.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi Tony and Maxim,
Thanks for your responses.
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 remove_device has already been called.
*** 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 occuring in frame # 0 when we try to call lower
level driver (D0) which has been detached already.
I will also post this query to [ntdev] list.
But again PnP helps a lot here.
Any pointers that you can possibly give here ?
Thanks,
Ukis
On Thu, May 28, 2015 at 11:13 PM, Maxim S. Shatskih
wrote:
> >recollection is that storage stack filters aren’t supposed to delete
> their device objects (or there’s
> >some complexity in this area).
>
> Surely the storage stack filter DOs are deleted, for instance, FveVol
> (BitLocker) and VolSnap.
>
> The complexity is that it is very hard to delete the non-PnP block
> storage DO itself in a proper way, with the FS mounted on it. But again PnP
> helps a lot here.
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>