Hello,
I am developing a simple minifilter driver. I’ve just encountered a strange situation.
On Post Create callback I’m trying to attach existing stream context to particular file by file ID. Most of time everything is going as expected, but sometimes I see really strange behavior:
- Opening a file test.bin causes two stream attachments:
- one to file with ID x (matching stream context is found in my stream contexts store - I assume it was created before the open in which I’m interested)
- another to file with ID y (stream context is allocated and set using FltSetStreamContext)
-
Synchronous paging writes are coming to file with ID x. I send them to the backend store. These operations complete with success.
-
After some time, another thread is triggered to transfer data from backend store to original destination. I fill in structures dedicated to FltCreateFileEx using file with ID x path (from stream context) - the instance is obtained using FltGetVolumeFromName and FltGetVolumeInstanceFromName, the path in OBJECT_ATTRIBUTES is the path from the context itself.
FltCreateFileEx causes… open to file with ID y.
-
After opening, I’m writing the data using the handle and file object to file id Y (this must not happen) with FltWriteFile.
-
Next unbuffered read to observed file causes open to file with ID y, but the data is corrupted. Instead of written bytes, I see there some stuff probably from NTFS Indexer (the header starts with INDX(…).
I did some research and found out below:
A. SCB (FsContext field from FILE_OBJECT) is stored in stream contexts, and differs between two stream contexts in above situation.
B. Two stream contexts for the same file have different instance contexts attached:
-
X has:
FLT_INSTANCE: fffffa800fe25480 “MyFltr Instance” “310200”
FLT_OBJECT: fffffa800fe25480 [01000000] Instance
RundownRef : 0x0000000000000000 (0)
PointerCount : 0x00000002
PrimaryLink : [fffffa8010d0a1e0-fffffa80082d9108]
OperationRundownRef : fffffa8008b35cb0
Could not read field “Number” of fltmgr!_EX_RUNDOWN_REF_CACHE_AWARE from address: fffffa8008b35cb0
Flags : [00000000]
Volume : fffffa80082d9010 “\Device\HarddiskVolume3”
Filter : fffffa800fb1e2d0 “MyFltr”
TrackCompletionNodes : fffffa8014b50a10
ContextLock : (fffffa800fe254f0)
Context : fffffa800ff07e90
CallbackNodes : (fffffa800fe25510)
VolumeLink : [fffffa8010d0a1e0-fffffa80082d9108]
FilterLink : [fffffa8014c901c0-fffffa801131c070]
-
Y has:
FLT_INSTANCE: fffffa800f15b650 “MyFltr Instance” “310200”
FLT_OBJECT: fffffa800f15b650 [01000000] Instance
RundownRef : 0x0000000000000000 (0)
PointerCount : 0x00000002
PrimaryLink : [fffffa8010d37a10-fffffa8009cba108]
OperationRundownRef : fffffa8010094620
Could not read field “Number” of fltmgr!_EX_RUNDOWN_REF_CACHE_AWARE from address: fffffa8010094620
Flags : [00000000]
Volume : fffffa8009cba010 “\Device\HarddiskVolume3”
Filter : fffffa800fb1e2d0 “MyFltr”
TrackCompletionNodes : fffffa80074f6b20
ContextLock : (fffffa800f15b6c0)
Context : fffffa800dbfb2a0
CallbackNodes : (fffffa800f15b6e0)
VolumeLink : [fffffa8010d37a10-fffffa8009cba108]
FilterLink : [fffffa800fb1e390-fffffa8014c901c0]
C. Volumes pointed by FLT_INSTANCEs are different, they share only DiskDeviceObject.
Here comes my questions:
- Is the file ID shared between all file streams? I thought yes, and that’s why I was shocked when I saw indexer header.
- Why two instances with the same altitude and volume name were created?
KK
Hmm… Why do you have two volumes with the same name but different pointers
?
fffffa80082d9010 “\Device\HarddiskVolume3” vs.
fffffa8009cba010 “\Device\HarddiskVolume3”
Thanks,
Alex
On Tue, Sep 29, 2015 at 2:03 AM, wrote:
> Hello,
>
> I am developing a simple minifilter driver. I’ve just encountered a
> strange situation.
>
> On Post Create callback I’m trying to attach existing stream context to
> particular file by file ID. Most of time everything is going as expected,
> but sometimes I see really strange behavior:
>
> 1. Opening a file test.bin causes two stream attachments:
> - one to file with ID x (matching stream context is found in my stream
> contexts store - I assume it was created before the open in which I’m
> interested)
> - another to file with ID y (stream context is allocated and set using
> FltSetStreamContext)
>
> 2. Synchronous paging writes are coming to file with ID x. I send them to
> the backend store. These operations complete with success.
>
> 3. After some time, another thread is triggered to transfer data from
> backend store to original destination. I fill in structures dedicated to
> FltCreateFileEx using file with ID x path (from stream context) - the
> instance is obtained using FltGetVolumeFromName and
> FltGetVolumeInstanceFromName, the path in OBJECT_ATTRIBUTES is the path
> from the context itself.
>
> FltCreateFileEx causes… open to file with ID y.
>
> 4. After opening, I’m writing the data using the handle and file object to
> file id Y (this must not happen) with FltWriteFile.
>
> 5. Next unbuffered read to observed file causes open to file with ID y,
> but the data is corrupted. Instead of written bytes, I see there some stuff
> probably from NTFS Indexer (the header starts with INDX(…).
>
> I did some research and found out below:
>
> A. SCB (FsContext field from FILE_OBJECT) is stored in stream contexts,
> and differs between two stream contexts in above situation.
>
> B. Two stream contexts for the same file have different instance contexts
> attached:
> - X has:
> FLT_INSTANCE: fffffa800fe25480 “MyFltr Instance” “310200”
> FLT_OBJECT: fffffa800fe25480 [01000000] Instance
> RundownRef : 0x0000000000000000 (0)
> PointerCount : 0x00000002
> PrimaryLink : [fffffa8010d0a1e0-fffffa80082d9108]
> OperationRundownRef : fffffa8008b35cb0
> Could not read field “Number” of fltmgr!_EX_RUNDOWN_REF_CACHE_AWARE from
> address: fffffa8008b35cb0
> Flags : [00000000]
> Volume : fffffa80082d9010 “\Device\HarddiskVolume3”
> Filter : fffffa800fb1e2d0 “MyFltr”
> TrackCompletionNodes : fffffa8014b50a10
> ContextLock : (fffffa800fe254f0)
> Context : fffffa800ff07e90
> CallbackNodes : (fffffa800fe25510)
> VolumeLink : [fffffa8010d0a1e0-fffffa80082d9108]
> FilterLink : [fffffa8014c901c0-fffffa801131c070]
>
> - Y has:
> FLT_INSTANCE: fffffa800f15b650 “MyFltr Instance” “310200”
> FLT_OBJECT: fffffa800f15b650 [01000000] Instance
> RundownRef : 0x0000000000000000 (0)
> PointerCount : 0x00000002
> PrimaryLink : [fffffa8010d37a10-fffffa8009cba108]
> OperationRundownRef : fffffa8010094620
> Could not read field “Number” of fltmgr!_EX_RUNDOWN_REF_CACHE_AWARE from
> address: fffffa8010094620
> Flags : [00000000]
> Volume : fffffa8009cba010 “\Device\HarddiskVolume3”
> Filter : fffffa800fb1e2d0 “MyFltr”
> TrackCompletionNodes : fffffa80074f6b20
> ContextLock : (fffffa800f15b6c0)
> Context : fffffa800dbfb2a0
> CallbackNodes : (fffffa800f15b6e0)
> VolumeLink : [fffffa8010d37a10-fffffa8009cba108]
> FilterLink : [fffffa800fb1e390-fffffa8014c901c0]
>
> C. Volumes pointed by FLT_INSTANCEs are different, they share only
> DiskDeviceObject.
>
> Here comes my questions:
> - Is the file ID shared between all file streams? I thought yes, and
> that’s why I was shocked when I saw indexer header.
> - Why two instances with the same altitude and volume name were created?
>
> KK
>
> —
> 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
>
Hi Alex,
Thanks for the reply.
Hmm… Why do you have two volumes with the same name but different pointers
?
fffffa80082d9010 “\Device\HarddiskVolume3” vs.
fffffa8009cba010 “\Device\HarddiskVolume3”
And that’s my question. They are both created inside the same frame. Below is the dump.
The first one:
FLT_VOLUME: fffffa80082d9010 “\Device\HarddiskVolume3”
FLT_OBJECT: fffffa80082d9010 [04000000] Volume
RundownRef : 0x0000000000000006 (3)
PointerCount : 0x00000001
PrimaryLink : [fffffa8010d39800-fffffa800ff2f020]
Frame : fffffa80074a8790 “Frame 0”
Flags : [00000064] SetupNotifyCalled EnableNameCaching FilterAttached
FileSystemType : [00000002] FLT_FSTYPE_NTFS
VolumeLink : [fffffa8010d39800-fffffa800ff2f020]
DeviceObject : fffffa800910cde0
DiskDeviceObject : fffffa800794acd0
FrameZeroVolume : fffffa80082d9010
VolumeInNextFrame : 0000000000000000
Guid : “”
CDODeviceName : “\Ntfs”
CDODriverName : “\FileSystem\Ntfs”
TargetedOpenCount : 0
Callbacks : (fffffa80082d9120)
ContextLock : (fffffa80082d9508)
VolumeContexts : (fffffa80082d9510) Count=0
StreamListCtrls : (fffffa80082d9518) rCount=6
FileListCtrls : (fffffa80082d9598) rCount=0
NameCacheCtrl : (fffffa80082d9618)
InstanceList : (fffffa80082d90a0)
FLT_INSTANCE: fffffa800fe25480 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa8010d0a1d0 “FileInfo” “45000”
And the second:
FLT_VOLUME: fffffa8009cba010 “\Device\HarddiskVolume3”
FLT_OBJECT: fffffa8009cba010 [04000000] Volume
RundownRef : 0x0000000000000006 (3)
PointerCount : 0x00000001
PrimaryLink : [fffffa800d9db800-fffffa8010d39800]
Frame : fffffa80074a8790 “Frame 0”
Flags : [00000064] SetupNotifyCalled EnableNameCaching FilterAttached
FileSystemType : [00000002] FLT_FSTYPE_NTFS
VolumeLink : [fffffa800d9db800-fffffa8010d39800]
DeviceObject : fffffa800904f650
DiskDeviceObject : fffffa800794acd0
FrameZeroVolume : fffffa8009cba010
VolumeInNextFrame : 0000000000000000
Guid : “”
CDODeviceName : “\Ntfs”
CDODriverName : “\FileSystem\Ntfs”
TargetedOpenCount : 0
Callbacks : (fffffa8009cba120)
ContextLock : (fffffa8009cba508)
VolumeContexts : (fffffa8009cba510) Count=0
StreamListCtrls : (fffffa8009cba518) rCount=88
FileListCtrls : (fffffa8009cba598) rCount=0
NameCacheCtrl : (fffffa8009cba618)
InstanceList : (fffffa8009cba0a0)
FLT_INSTANCE: fffffa800f15b650 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa8010d37a00 “FileInfo” “45000”
When I executed !drvobj \Driver\volmgr, on the device object list there is only one responsible for \Device\HarddiskVolume3.
In what conditions filter manager creates its objects (in this case FLT_VOLUME) multiple times inside the same frame?
Hmm still pretty weird. So Frame0 is the same across all volumes so it’s
not surprising. However, if you look at the two volumes, DeviceObject and
FrameZeroVolume are different.
So if you do !devobj on the DeviceObject for each volume you’ll see the
underlying FS volume they’re attached to:
!devobj 862e1dd8
Device object (862e1dd8) is for:
\FileSystem\FltMgr DriverObject 85a12660
Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
DevExt 862e1e90 DevObjExt 862e1ec0
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedTo (Lower) 862ba020 \FileSystem\Ntfs
Device queue is not busy.
So then you can see that the lower device is 862ba020 and it belongs to
NTFS:
!devobj 862ba020
Device object (862ba020) is for:
\FileSystem\Ntfs DriverObject 85a0c660
Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
DevExt 862ba0d8 DevObjExt 862bafb0
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) 862e1dd8 \FileSystem\FltMgr
Device queue is not busy.
You can see all of NTFS’ DeviceObjects like so:
!drvobj NTFS
Driver object (85a0c660) is for:
\FileSystem\Ntfs
Driver Extension List: (id , addr)
Device Object list:
87e61020 85073020 85072020 862ba020
85a2f630
So could you please try this on both volumes and see if anything looks
suspicious ?
On Wed, Sep 30, 2015 at 12:17 AM, wrote:
> Hi Alex,
>
> > Thanks for the reply.
> >
> > Hmm… Why do you have two volumes with the same name but different
> pointers
> > ?
> >
> > fffffa80082d9010 “\Device\HarddiskVolume3” vs.
> > fffffa8009cba010 “\Device\HarddiskVolume3”
>
> And that’s my question. They are both created inside the same frame. Below
> is the dump.
>
> The first one:
> FLT_VOLUME: fffffa80082d9010 “\Device\HarddiskVolume3”
> FLT_OBJECT: fffffa80082d9010 [04000000] Volume
> RundownRef : 0x0000000000000006 (3)
> PointerCount : 0x00000001
> PrimaryLink : [fffffa8010d39800-fffffa800ff2f020]
> Frame : fffffa80074a8790 “Frame 0”
> Flags : [00000064] SetupNotifyCalled
> EnableNameCaching FilterAttached
> FileSystemType : [00000002] FLT_FSTYPE_NTFS
> VolumeLink : [fffffa8010d39800-fffffa800ff2f020]
> DeviceObject : fffffa800910cde0
> DiskDeviceObject : fffffa800794acd0
> FrameZeroVolume : fffffa80082d9010
> VolumeInNextFrame : 0000000000000000
> Guid : “”
> CDODeviceName : “\Ntfs”
> CDODriverName : “\FileSystem\Ntfs”
> TargetedOpenCount : 0
> Callbacks : (fffffa80082d9120)
> ContextLock : (fffffa80082d9508)
> VolumeContexts : (fffffa80082d9510) Count=0
> StreamListCtrls : (fffffa80082d9518) rCount=6
> FileListCtrls : (fffffa80082d9598) rCount=0
> NameCacheCtrl : (fffffa80082d9618)
> InstanceList : (fffffa80082d90a0)
> FLT_INSTANCE: fffffa800fe25480 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8010d0a1d0 “FileInfo” “45000”
>
> And the second:
> FLT_VOLUME: fffffa8009cba010 “\Device\HarddiskVolume3”
> FLT_OBJECT: fffffa8009cba010 [04000000] Volume
> RundownRef : 0x0000000000000006 (3)
> PointerCount : 0x00000001
> PrimaryLink : [fffffa800d9db800-fffffa8010d39800]
> Frame : fffffa80074a8790 “Frame 0”
> Flags : [00000064] SetupNotifyCalled
> EnableNameCaching FilterAttached
> FileSystemType : [00000002] FLT_FSTYPE_NTFS
> VolumeLink : [fffffa800d9db800-fffffa8010d39800]
> DeviceObject : fffffa800904f650
> DiskDeviceObject : fffffa800794acd0
> FrameZeroVolume : fffffa8009cba010
> VolumeInNextFrame : 0000000000000000
> Guid : “”
> CDODeviceName : “\Ntfs”
> CDODriverName : “\FileSystem\Ntfs”
> TargetedOpenCount : 0
> Callbacks : (fffffa8009cba120)
> ContextLock : (fffffa8009cba508)
> VolumeContexts : (fffffa8009cba510) Count=0
> StreamListCtrls : (fffffa8009cba518) rCount=88
> FileListCtrls : (fffffa8009cba598) rCount=0
> NameCacheCtrl : (fffffa8009cba618)
> InstanceList : (fffffa8009cba0a0)
> FLT_INSTANCE: fffffa800f15b650 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8010d37a00 “FileInfo” “45000”
>
> When I executed !drvobj \Driver\volmgr, on the device object list there is
> only one responsible for \Device\HarddiskVolume3.
>
> In what conditions filter manager creates its objects (in this case
> FLT_VOLUME) multiple times inside the same frame?
>
> —
> 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
>
Sure, I’ve done this actually. Here are the outputs:
-
First one
2: kd> !devobj fffffa800910cde0
Device object (fffffa800910cde0) is for:
\FileSystem\FltMgr DriverObject fffffa80074b7550
Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
DevExt fffffa800910cf30 DevObjExt fffffa800910cf88
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0000000000)
AttachedTo (Lower) fffffa800edcb030 \FileSystem\Ntfs
Device queue is not busy.
2: kd> !devobj fffffa800edcb030
Device object (fffffa800edcb030) is for:
\FileSystem\Ntfs DriverObject fffffa8007841730
Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
DevExt fffffa800edcb180 DevObjExt fffffa800edccad0
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0000000000)
AttachedDevice (Upper) fffffa800910cde0 \FileSystem\FltMgr
Device queue is not busy.
-
Second one
2: kd> !devobj fffffa800904f650
Device object (fffffa800904f650) is for:
\FileSystem\FltMgr DriverObject fffffa80074b7550
Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
DevExt fffffa800904f7a0 DevObjExt fffffa800904f7f8
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0000000000)
AttachedTo (Lower) fffffa8007c51030 \FileSystem\Ntfs
Device queue is not busy.
2: kd> !devobj fffffa8007c51030
Device object (fffffa8007c51030) is for:
\FileSystem\Ntfs DriverObject fffffa8007841730
Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
DevExt fffffa8007c51180 DevObjExt fffffa8007c52ad0
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0000000000)
AttachedDevice (Upper) fffffa800904f650 \FileSystem\FltMgr
Device queue is not busy.
-
drvobj! on ntfs
2: kd> !drvobj ntfs
Driver object (fffffa8007841730) is for:
\FileSystem\Ntfs
Driver Extension List: (id , addr)
Device Object list:
fffffa8007c51030 fffffa800f982030 fffffa800edcb030 fffffa8009be7030
fffffa8007171030 fffffa800818f030 fffffa8007b7f030 fffffa8007875060
- And a bonus, !fltkd.volumes output
2: kd> !fltkd.volumes
Volume List: fffffa80074a88c0 “Frame 0”
FLT_VOLUME: fffffa800750d810 “\Device\Mup”
FLT_INSTANCE: fffffa80074eaa80 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa800750d3b0 “FileInfo” “45000”
FLT_VOLUME: fffffa80069eb800 “\Device\HarddiskVolume1”
FLT_INSTANCE: fffffa80095ef4a0 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa8008945010 “luafv” “135000”
FLT_INSTANCE: fffffa80079efbb0 “FileInfo” “45000”
FLT_VOLUME: fffffa80082e5010 “\Device\HarddiskVolume2”
FLT_INSTANCE: fffffa8009af0750 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa8008324bb0 “FileInfo” “45000”
FLT_VOLUME: fffffa80070bc6f0 “\Device\HarddiskVolumeShadowCopy19”
FLT_INSTANCE: fffffa800fd5e010 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa80072a4690 “FileInfo” “45000”
FLT_VOLUME: fffffa800ff2f010 “\Device\HarddiskVolumeShadowCopy20”
FLT_INSTANCE: fffffa801131c010 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa80096e3010 “FileInfo” “45000”
FLT_VOLUME: fffffa80082d9010 “\Device\HarddiskVolume3”
FLT_INSTANCE: fffffa800fe25480 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa8010d0a1d0 “FileInfo” “45000”
FLT_VOLUME: fffffa8010d397f0 “\Device\HarddiskVolumeShadowCopy21”
FLT_INSTANCE: fffffa8014c90160 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa800f9de140 “FileInfo” “45000”
FLT_VOLUME: fffffa8009cba010 “\Device\HarddiskVolume3”
FLT_INSTANCE: fffffa800f15b650 “MyFltr Instance” “310200”
FLT_INSTANCE: fffffa8010d37a00 “FileInfo” “45000”
FLT_VOLUME: fffffa800d9db7f0 “\Device\HarddiskVolume10”
FLT_INSTANCE: fffffa80099bd800 “FileInfo” “45000”
Is this not against the Filter Manager or even NTFS spec? I was sure that NTFS can attach itself only once to each mounted volume.
Still not sure what’s going on but it looks like there are two NTFS devices
for the same volume (or at least the same name volume)… At this point
this isn’t really FltMgr’s problem (as it is attaching to each file system
volume it sees) but rather NTFS’… It’d be very interesting to see why
that happened…
Thanks,
Alex
On Wed, Sep 30, 2015 at 11:34 AM, wrote:
> Sure, I’ve done this actually. Here are the outputs:
>
> - First one
> 2: kd> !devobj fffffa800910cde0
> Device object (fffffa800910cde0) is for:
> \FileSystem\FltMgr DriverObject fffffa80074b7550
> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
> DevExt fffffa800910cf30 DevObjExt fffffa800910cf88
> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
> Characteristics (0000000000)
> AttachedTo (Lower) fffffa800edcb030 \FileSystem\Ntfs
> Device queue is not busy.
> 2: kd> !devobj fffffa800edcb030
> Device object (fffffa800edcb030) is for:
> \FileSystem\Ntfs DriverObject fffffa8007841730
> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
> DevExt fffffa800edcb180 DevObjExt fffffa800edccad0
> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
> Characteristics (0000000000)
> AttachedDevice (Upper) fffffa800910cde0 \FileSystem\FltMgr
> Device queue is not busy.
>
> - Second one
> 2: kd> !devobj fffffa800904f650
> Device object (fffffa800904f650) is for:
> \FileSystem\FltMgr DriverObject fffffa80074b7550
> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
> DevExt fffffa800904f7a0 DevObjExt fffffa800904f7f8
> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
> Characteristics (0000000000)
> AttachedTo (Lower) fffffa8007c51030 \FileSystem\Ntfs
> Device queue is not busy.
> 2: kd> !devobj fffffa8007c51030
> Device object (fffffa8007c51030) is for:
> \FileSystem\Ntfs DriverObject fffffa8007841730
> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
> DevExt fffffa8007c51180 DevObjExt fffffa8007c52ad0
> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
> Characteristics (0000000000)
> AttachedDevice (Upper) fffffa800904f650 \FileSystem\FltMgr
> Device queue is not busy.
>
> - drvobj! on ntfs
> 2: kd> !drvobj ntfs
> Driver object (fffffa8007841730) is for:
> \FileSystem\Ntfs
> Driver Extension List: (id , addr)
>
> Device Object list:
> fffffa8007c51030 fffffa800f982030 fffffa800edcb030 fffffa8009be7030
> fffffa8007171030 fffffa800818f030 fffffa8007b7f030 fffffa8007875060
>
> - And a bonus, !fltkd.volumes output
> 2: kd> !fltkd.volumes
>
> Volume List: fffffa80074a88c0 “Frame 0”
> FLT_VOLUME: fffffa800750d810 “\Device\Mup”
> FLT_INSTANCE: fffffa80074eaa80 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa800750d3b0 “FileInfo” “45000”
> FLT_VOLUME: fffffa80069eb800 “\Device\HarddiskVolume1”
> FLT_INSTANCE: fffffa80095ef4a0 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8008945010 “luafv” “135000”
> FLT_INSTANCE: fffffa80079efbb0 “FileInfo” “45000”
> FLT_VOLUME: fffffa80082e5010 “\Device\HarddiskVolume2”
> FLT_INSTANCE: fffffa8009af0750 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8008324bb0 “FileInfo” “45000”
> FLT_VOLUME: fffffa80070bc6f0 “\Device\HarddiskVolumeShadowCopy19”
> FLT_INSTANCE: fffffa800fd5e010 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa80072a4690 “FileInfo” “45000”
> FLT_VOLUME: fffffa800ff2f010 “\Device\HarddiskVolumeShadowCopy20”
> FLT_INSTANCE: fffffa801131c010 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa80096e3010 “FileInfo” “45000”
> FLT_VOLUME: fffffa80082d9010 “\Device\HarddiskVolume3”
> FLT_INSTANCE: fffffa800fe25480 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8010d0a1d0 “FileInfo” “45000”
> FLT_VOLUME: fffffa8010d397f0 “\Device\HarddiskVolumeShadowCopy21”
> FLT_INSTANCE: fffffa8014c90160 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa800f9de140 “FileInfo” “45000”
> FLT_VOLUME: fffffa8009cba010 “\Device\HarddiskVolume3”
> FLT_INSTANCE: fffffa800f15b650 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8010d37a00 “FileInfo” “45000”
> FLT_VOLUME: fffffa800d9db7f0 “\Device\HarddiskVolume10”
> FLT_INSTANCE: fffffa80099bd800 “FileInfo” “45000”
>
> Is this not against the Filter Manager or even NTFS spec? I was sure that
> NTFS can attach itself only once to each mounted volume.
>
> —
> 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
>
Isn’t this what will occur when a volume is dismounted? The original
instance remains until all files are closed, but new opens are routed to
the currently mounted instance. To verify this theory, check the Vpbs
on the FileObjects.
I think this suggests that step #3 in the original mail is problematic,
because it’s assuming that reassembling a full device name is sufficient
to route to the same instance. This is not correct - the instance needs
to be explicitly recorded to ensure the open goes to the same instance.
If this is done, the open in #3 should fail, because that volume
instance is no longer valid for new requests.
In general though handling dismounts ends up being more extensive for
most filters than just ensuring creates are sent to the original
instance. The exact processing depends a lot on the specific filter.
On 09/30/2015 01:43 PM, Alex Carp wrote:
Still not sure what’s going on but it looks like there are two NTFS
devices for the same volume (or at least the same name volume)… At
this point this isn’t really FltMgr’s problem (as it is attaching to
each file system volume it sees) but rather NTFS’… It’d be very
interesting to see why that happened…
Thanks,
Alex
On Wed, Sep 30, 2015 at 11:34 AM, > mailto:xxxxx> wrote:
>
> Sure, I’ve done this actually. Here are the outputs:
>
> - First one
> 2: kd> !devobj fffffa800910cde0
> Device object (fffffa800910cde0) is for:
> \FileSystem\FltMgr DriverObject fffffa80074b7550
> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
> DevExt fffffa800910cf30 DevObjExt fffffa800910cf88
> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
> Characteristics (0000000000)
> AttachedTo (Lower) fffffa800edcb030 \FileSystem\Ntfs
> Device queue is not busy.
> 2: kd> !devobj fffffa800edcb030
> Device object (fffffa800edcb030) is for:
> \FileSystem\Ntfs DriverObject fffffa8007841730
> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
> DevExt fffffa800edcb180 DevObjExt fffffa800edccad0
> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
> Characteristics (0000000000)
> AttachedDevice (Upper) fffffa800910cde0 \FileSystem\FltMgr
> Device queue is not busy.
>
> - Second one
> 2: kd> !devobj fffffa800904f650
> Device object (fffffa800904f650) is for:
> \FileSystem\FltMgr DriverObject fffffa80074b7550
> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
> DevExt fffffa800904f7a0 DevObjExt fffffa800904f7f8
> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
> Characteristics (0000000000)
> AttachedTo (Lower) fffffa8007c51030 \FileSystem\Ntfs
> Device queue is not busy.
> 2: kd> !devobj fffffa8007c51030
> Device object (fffffa8007c51030) is for:
> \FileSystem\Ntfs DriverObject fffffa8007841730
> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
> DevExt fffffa8007c51180 DevObjExt fffffa8007c52ad0
> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
> Characteristics (0000000000)
> AttachedDevice (Upper) fffffa800904f650 \FileSystem\FltMgr
> Device queue is not busy.
>
> - drvobj! on ntfs
> 2: kd> !drvobj ntfs
> Driver object (fffffa8007841730) is for:
> \FileSystem\Ntfs
> Driver Extension List: (id , addr)
>
> Device Object list:
> fffffa8007c51030 fffffa800f982030 fffffa800edcb030 fffffa8009be7030
> fffffa8007171030 fffffa800818f030 fffffa8007b7f030 fffffa8007875060
>
> - And a bonus, !fltkd.volumes output
> 2: kd> !fltkd.volumes
>
> Volume List: fffffa80074a88c0 “Frame 0”
> FLT_VOLUME: fffffa800750d810 “\Device\Mup”
> FLT_INSTANCE: fffffa80074eaa80 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa800750d3b0 “FileInfo” “45000”
> FLT_VOLUME: fffffa80069eb800 “\Device\HarddiskVolume1”
> FLT_INSTANCE: fffffa80095ef4a0 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8008945010 “luafv” “135000”
> FLT_INSTANCE: fffffa80079efbb0 “FileInfo” “45000”
> FLT_VOLUME: fffffa80082e5010 “\Device\HarddiskVolume2”
> FLT_INSTANCE: fffffa8009af0750 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8008324bb0 “FileInfo” “45000”
> FLT_VOLUME: fffffa80070bc6f0 “\Device\HarddiskVolumeShadowCopy19”
> FLT_INSTANCE: fffffa800fd5e010 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa80072a4690 “FileInfo” “45000”
> FLT_VOLUME: fffffa800ff2f010 “\Device\HarddiskVolumeShadowCopy20”
> FLT_INSTANCE: fffffa801131c010 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa80096e3010 “FileInfo” “45000”
> FLT_VOLUME: fffffa80082d9010 “\Device\HarddiskVolume3”
> FLT_INSTANCE: fffffa800fe25480 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8010d0a1d0 “FileInfo” “45000”
> FLT_VOLUME: fffffa8010d397f0 “\Device\HarddiskVolumeShadowCopy21”
> FLT_INSTANCE: fffffa8014c90160 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa800f9de140 “FileInfo” “45000”
> FLT_VOLUME: fffffa8009cba010 “\Device\HarddiskVolume3”
> FLT_INSTANCE: fffffa800f15b650 “MyFltr Instance” “310200”
> FLT_INSTANCE: fffffa8010d37a00 “FileInfo” “45000”
> FLT_VOLUME: fffffa800d9db7f0 “\Device\HarddiskVolume10”
> FLT_INSTANCE: fffffa80099bd800 “FileInfo” “45000”
>
> Is this not against the Filter Manager or even NTFS spec? I was sure
> that NTFS can attach itself only once to each mounted volume.
>
> —
> 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
>
></mailto:xxxxx>
Duh, didn’t even occur to me… Thanks Malcolm!
On Thu, Oct 1, 2015 at 12:23 AM, Malcolm Smith [MSFT]
wrote:
> Isn’t this what will occur when a volume is dismounted? The original
> instance remains until all files are closed, but new opens are routed to
> the currently mounted instance. To verify this theory, check the Vpbs on
> the FileObjects.
>
> I think this suggests that step #3 in the original mail is problematic,
> because it’s assuming that reassembling a full device name is sufficient to
> route to the same instance. This is not correct - the instance needs to be
> explicitly recorded to ensure the open goes to the same instance. If this
> is done, the open in #3 should fail, because that volume instance is no
> longer valid for new requests.
>
> In general though handling dismounts ends up being more extensive for most
> filters than just ensuring creates are sent to the original instance. The
> exact processing depends a lot on the specific filter.
>
> - M
>
> On 09/30/2015 01:43 PM, Alex Carp wrote:
>
>> Still not sure what’s going on but it looks like there are two NTFS
>> devices for the same volume (or at least the same name volume)… At
>> this point this isn’t really FltMgr’s problem (as it is attaching to
>> each file system volume it sees) but rather NTFS’… It’d be very
>> interesting to see why that happened…
>>
>> Thanks,
>> Alex
>>
>> On Wed, Sep 30, 2015 at 11:34 AM, >> mailto:xxxxx> wrote:
>>
>> Sure, I’ve done this actually. Here are the outputs:
>>
>> - First one
>> 2: kd> !devobj fffffa800910cde0
>> Device object (fffffa800910cde0) is for:
>> \FileSystem\FltMgr DriverObject fffffa80074b7550
>> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
>> DevExt fffffa800910cf30 DevObjExt fffffa800910cf88
>> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
>> Characteristics (0000000000)
>> AttachedTo (Lower) fffffa800edcb030 \FileSystem\Ntfs
>> Device queue is not busy.
>> 2: kd> !devobj fffffa800edcb030
>> Device object (fffffa800edcb030) is for:
>> \FileSystem\Ntfs DriverObject fffffa8007841730
>> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
>> DevExt fffffa800edcb180 DevObjExt fffffa800edccad0
>> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
>> Characteristics (0000000000)
>> AttachedDevice (Upper) fffffa800910cde0 \FileSystem\FltMgr
>> Device queue is not busy.
>>
>> - Second one
>> 2: kd> !devobj fffffa800904f650
>> Device object (fffffa800904f650) is for:
>> \FileSystem\FltMgr DriverObject fffffa80074b7550
>> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
>> DevExt fffffa800904f7a0 DevObjExt fffffa800904f7f8
>> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
>> Characteristics (0000000000)
>> AttachedTo (Lower) fffffa8007c51030 \FileSystem\Ntfs
>> Device queue is not busy.
>> 2: kd> !devobj fffffa8007c51030
>> Device object (fffffa8007c51030) is for:
>> \FileSystem\Ntfs DriverObject fffffa8007841730
>> Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
>> DevExt fffffa8007c51180 DevObjExt fffffa8007c52ad0
>> ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
>> Characteristics (0000000000)
>> AttachedDevice (Upper) fffffa800904f650 \FileSystem\FltMgr
>> Device queue is not busy.
>>
>> - drvobj! on ntfs
>> 2: kd> !drvobj ntfs
>> Driver object (fffffa8007841730) is for:
>> \FileSystem\Ntfs
>> Driver Extension List: (id , addr)
>>
>> Device Object list:
>> fffffa8007c51030 fffffa800f982030 fffffa800edcb030 fffffa8009be7030
>> fffffa8007171030 fffffa800818f030 fffffa8007b7f030 fffffa8007875060
>>
>> - And a bonus, !fltkd.volumes output
>> 2: kd> !fltkd.volumes
>>
>> Volume List: fffffa80074a88c0 “Frame 0”
>> FLT_VOLUME: fffffa800750d810 “\Device\Mup”
>> FLT_INSTANCE: fffffa80074eaa80 “MyFltr Instance” “310200”
>> FLT_INSTANCE: fffffa800750d3b0 “FileInfo” “45000”
>> FLT_VOLUME: fffffa80069eb800 “\Device\HarddiskVolume1”
>> FLT_INSTANCE: fffffa80095ef4a0 “MyFltr Instance” “310200”
>> FLT_INSTANCE: fffffa8008945010 “luafv” “135000”
>> FLT_INSTANCE: fffffa80079efbb0 “FileInfo” “45000”
>> FLT_VOLUME: fffffa80082e5010 “\Device\HarddiskVolume2”
>> FLT_INSTANCE: fffffa8009af0750 “MyFltr Instance” “310200”
>> FLT_INSTANCE: fffffa8008324bb0 “FileInfo” “45000”
>> FLT_VOLUME: fffffa80070bc6f0 “\Device\HarddiskVolumeShadowCopy19”
>> FLT_INSTANCE: fffffa800fd5e010 “MyFltr Instance” “310200”
>> FLT_INSTANCE: fffffa80072a4690 “FileInfo” “45000”
>> FLT_VOLUME: fffffa800ff2f010 “\Device\HarddiskVolumeShadowCopy20”
>> FLT_INSTANCE: fffffa801131c010 “MyFltr Instance” “310200”
>> FLT_INSTANCE: fffffa80096e3010 “FileInfo” “45000”
>> FLT_VOLUME: fffffa80082d9010 “\Device\HarddiskVolume3”
>> FLT_INSTANCE: fffffa800fe25480 “MyFltr Instance” “310200”
>> FLT_INSTANCE: fffffa8010d0a1d0 “FileInfo” “45000”
>> FLT_VOLUME: fffffa8010d397f0 “\Device\HarddiskVolumeShadowCopy21”
>> FLT_INSTANCE: fffffa8014c90160 “MyFltr Instance” “310200”
>> FLT_INSTANCE: fffffa800f9de140 “FileInfo” “45000”
>> FLT_VOLUME: fffffa8009cba010 “\Device\HarddiskVolume3”
>> FLT_INSTANCE: fffffa800f15b650 “MyFltr Instance” “310200”
>> FLT_INSTANCE: fffffa8010d37a00 “FileInfo” “45000”
>> FLT_VOLUME: fffffa800d9db7f0 “\Device\HarddiskVolume10”
>> FLT_INSTANCE: fffffa80099bd800 “FileInfo” “45000”
>>
>> Is this not against the Filter Manager or even NTFS spec? I was sure
>> that NTFS can attach itself only once to each mounted volume.
>>
>> —
>> 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
>>
>>
>>
>
> —
> 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
></mailto:xxxxx>
Thanks Malcolm,
Isn’t this what will occur when a volume is dismounted? The original
instance remains until all files are closed, but new opens are routed to
the currently mounted instance. To verify this theory, check the Vpbs
on the FileObjects.
I’ve read about this behavior, but I’ve never seen it.
I’m sure, that I didn’t dismount the volume intentionally. When my case happened, there was actually only a specific workload running on the test machine. Can Windows manually trigger volume dismount? If so, in what conditions?
Also, to be 100% sure - there aren’t any other cases, when two FLT_VOLUME instances points to the same underlying volume, are there?
>only a specific workload running on the test machine. Can Windows manually trigger volume
dismount? If so, in what conditions?
Drive letter revocation
chkdsk /f
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com