HIi
When is look for device stack, I found that filter manager had two device
object.
!devstack 89c7c138
!DevObj !DrvObj !DevExt ObjectName
89c7c138 \Driver\DxSpy 89c7c1f0
897bf7d8 \FileSystem\FltMgr 897bf890
8a12d960 \Driver\mfehidk 8a12da18
8a0f7ee8 \FileSystem\FltMgr 8a0f7fa0
8a0f4440 \FileSystem\Ntfs 8a0f44f8
Is there any specific reason for that.
Thanks
Ashish
I guess that is because of multiple Filter Manager frames being used on that device stack. Quote from the WDK:
“For interoperability with legacy filter drivers, the filter manager can attach filter device objects to a file system I/O stack in more than one location. Each of the filter manager’s filter device objects is called a frame. From the perspective of a legacy filter driver, each filter manager frame is just another legacy filter driver.”
Razvan
— On Thu, 9/24/09, Ashish Goyal wrote:
> From: Ashish Goyal
> Subject: [ntfsd] Filter Manager Loading
> To: “Windows File Systems Devs Interest List”
> Date: Thursday, September 24, 2009, 5:18 PM
> HIi
> When is look for device stack, I found that filter
> manager had two device object.
> ?
> !devstack 89c7c138
> ? !DevObj?? !DrvObj??? !DevExt??
> ObjectName
> > 89c7c138? \Driver\DxSpy??? 89c7c1f0?
>
> ? 897bf7d8? \FileSystem\FltMgr 897bf890?
> ? 8a12d960? \Driver\mfehidk??? 8a12da18?
>
> ? 8a0f7ee8? \FileSystem\FltMgr 8a0f7fa0?
> ? 8a0f4440? \FileSystem\Ntfs?? 8a0f44f8
> ?
> Is there any specific reason for that.
> ?
> Thanks
> Ashish
Hi!
You are seeing this because of the concept of multiple frames of filter
manager. Read more on filter manager frames for details.
Regards,
Ayush Gupta
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ashish Goyal
Sent: Thursday, September 24, 2009 7:48 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Filter Manager Loading
HIi
When is look for device stack, I found that filter manager had two device
object.
!devstack 89c7c138
!DevObj !DrvObj !DevExt ObjectName
89c7c138 \Driver\DxSpy 89c7c1f0
897bf7d8 \FileSystem\FltMgr 897bf890
8a12d960 \Driver\mfehidk 8a12da18
8a0f7ee8 \FileSystem\FltMgr 8a0f7fa0
8a0f4440 \FileSystem\Ntfs 8a0f44f8
Is there any specific reason for that.
Thanks
Ashish
— NTFSD is sponsored by OSR For our schedule of debugging and file system
seminars (including our new fs mini-filter seminar) 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
Thanks Razvan,
Actually we were having UNEXPECTED_KERNEL_MODE_TRAP which is Stack
Overflow. I have seen several recursive calls…From our driver we send
IRP_MJ_CREATE IRP to lower device object which is Fliter Manager and it get
routed back to us and so there is loop…
Is it re-entrancy problem or due to filter manager hooked at multiple
location. Is there any pattern which Filter manager follows to hook.
Thanks
Ashish
On Thu, Sep 24, 2009 at 8:00 PM, Razvan Hobeanu wrote:
> I guess that is because of multiple Filter Manager frames being used on
> that device stack. Quote from the WDK:
>
> “For interoperability with legacy filter drivers, the filter manager can
> attach filter device objects to a file system I/O stack in more than one
> location. Each of the filter manager’s filter device objects is called a
> frame. From the perspective of a legacy filter driver, each filter manager
> frame is just another legacy filter driver.”
>
> Razvan
>
> — On Thu, 9/24/09, Ashish Goyal wrote:
>
> > From: Ashish Goyal
> > Subject: [ntfsd] Filter Manager Loading
> > To: “Windows File Systems Devs Interest List”
> > Date: Thursday, September 24, 2009, 5:18 PM
> > HIi
> > When is look for device stack, I found that filter
> > manager had two device object.
> >
> > !devstack 89c7c138
> > !DevObj !DrvObj !DevExt
> > ObjectName
> > > 89c7c138 \Driver\DxSpy 89c7c1f0
> >
> > 897bf7d8 \FileSystem\FltMgr 897bf890
> > 8a12d960 \Driver\mfehidk 8a12da18
> >
> > 8a0f7ee8 \FileSystem\FltMgr 8a0f7fa0
> > 8a0f4440 \FileSystem\Ntfs 8a0f44f8
> >
> > Is there any specific reason for that.
> >
> > Thanks
> > Ashish
>
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>
> Actually we were having UNEXPECTED_KERNEL_MODE_TRAP
which is Stack Overflow. I have seen several recursive
calls…From our driver we send IRP_MJ_CREATE IRP to lower
device object which is Fliter Manager and it get routed
back to us and so there is loop…Is it re-entrancy problem or due to filter manager
hooked at multiple location. Is there any pattern which
Filter manager follows to hook.
Can you show us a stack dump in order to get a better look of it?
Razvan
Having two or more filter manager devices on a stack is perfectly normal (http://blogs.msdn.com/alexcarp/archive/2009/06/09/filter-manager-concepts-part-1-fltp-frame.aspx).
Could you please post a stack ?
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
Hi,
Our is DxSpy driver…Once we get filepath, We strip the filename and Call
OpenFile on Directory path which sends the IRP_MJ_CREATE irp.
STACK_TEXT:
b9a1b0fc 8091a3c8 ca5c0000 e15cd048 00000000 nt!MmUnmapViewInSystemCache+0xb
b9a1b114 808572a1 8a379be8 8a08c5b8 00000000 nt!CcUnmapVacb+0x2a
b9a1b178 8083026a 8a1555f0 04f93800 00000000 nt!CcGetVacbMiss+0x33d
b9a1b1b4 80936da4 8a1555f0 04f93800 00000000 nt!CcGetVirtualAddress+0xb7
b9a1b1d8 80936f6a 8a08f028 b9a1b264 00000400 nt!CcMapDataCommon+0x4a
b9a1b234 f727af2d 8a08f028 b9a1b264 00000400 nt!CcMapData+0x55
b9a1b254 f7278494 b9a1babc 8a1694d0 04f93800 Ntfs!NtfsMapStream+0x4b
b9a1b2c8 f727adf0 b9a1babc 8a0f8100 e4da7010 Ntfs!NtfsReadMftRecord+0x86
b9a1b300 f727afac b9a1babc 8a0f8100 e4da7010 Ntfs!NtfsReadFileRecord+0x7a
b9a1b338 f72398a8 b9a1babc e4da7008 e4da7010
Ntfs!NtfsLookupInFileRecord+0x37
b9a1b448 f727cc14 b9a1babc e4da70d0 00000000 Ntfs!NtfsLookupAllocation+0xdd
b9a1b48c f727cfe6 b9a1babc e4da70d0 00000000 Ntfs!LookupLcns+0x3a
b9a1b608 f727f6aa b9a1babc e4da70d0 861b9e88 Ntfs!NtfsWriteLog+0x4f6
b9a1b79c f727f786 b9a1babc e4da70d0 e4e77320
Ntfs!NtfsUpdateFileNameInIndex+0x128
b9a1b898 f727f8c6 b9a1babc e4e77008 e4e772d0
Ntfs!NtfsUpdateDuplicateInfo+0x2b0
b9a1baa0 f727c8d9 b9a1babc 8764d880 00000000 Ntfs!NtfsCommonCleanup+0x1e82
b9a1bc10 80840153 8a0f8020 8764d880 8764d880 Ntfs!NtfsFsdCleanup+0xcf
b9a1bc24 f731eb25 8a135930 8764d880 8a0c99b8 nt!IofCallDriver+0x45
b9a1bc48 f731ecf5 b9a1bc68 8a135930 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b9a1bc80 80840153 8a135930 8764d880 8764d880 fltmgr!FltpDispatch+0x11f
b9a1bc94 f7130f2d 8a2019a8 8a0837a8 8a135930 nt!IofCallDriver+0x45
WARNING: Stack unwind information not available. Following frames may be
wrong.
b9a1bcb8 80840153 8a0837a8 8764d880 8764d880
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x80
b9a1bccc f731ed28 8764d890 8a31d538 8951f8e8 nt!IofCallDriver+0x45
b9a1bcf8 80840153 897cb020 8764d880 8764d880 fltmgr!FltpDispatch+0x152
b9a1bd0c 8092ec0a 8951f8d0 8a372e70 8951f8e8 nt!IofCallDriver+0x4
b9a1bd3c 8092b6af 8a38c478 897cb020 00000000 nt!IopCloseFile+0x2ae
b9a1bd6c 8092b852 8a38c478 00000001 8a372e70 nt!ObpDecrementHandleCount+0xcc
b9a1bd94 8092b776 e1002e18 8951f8e8 00002960
nt!ObpCloseHandleTableEntry+0x131
b9a1bdd8 8092b7c1 00002960 00000000 b9a1bdf4 nt!ObpCloseHandle+0x82
b9a1bde8 80833bef 80002960 b9a1bf0c 8083b01c nt!NtClose+0x1b
b9a1bde8 8083b01c 80002960 b9a1bf0c 8083b01c nt!KiFastCallEntry+0xfc
b9a1be64 b9a3ef1b 80002960 00000000 86a49934 nt!ZwClose+0x11
b9a1bf0c b9a3efaf ead819a4 897b25d0 b9a1bf5f QFAPFlt+0x4f1b
b9a1bf3c b9a3f184 ead819a4 8754ac58 897b25d0 QFAPFlt+0x4faf
b9a1bf60 b9a3f711 ead819a4 86a49934 b9a1bfac QFAPFlt+0x5184
b9a1bf84 b9a4059a b9a1bfa4 86a49934 b9a1c020 QFAPFlt+0x5711
b9a1c000 f731c4ca 86a49934 b9a1c020 b9a1c03c QFAPFlt+0x659a
b9a1c060 f731df2a 00a1c0a4 86a498d8 89155fdc
fltmgr!FltpPerformPreCallbacks+0x2d4
b9a1c074 f732c0ad b9a1c0a4 f732a540 00000000
fltmgr!FltpPassThroughInternal+0x32
b9a1c08c f732c5cc b9a1c0a4 878df558 884de9d8 fltmgr!FltpCreateInternal+0x63
b9a1c0c0 80840153 897cb020 89155d98 8a1b3638 fltmgr!FltpCreate+0x258
b9a1c0d4 b98009a2 884de9d8 8a1b3638 878df558 nt!IofCallDriver+0x45
b9a1c210 b97f821b 884de9d8 897cb020 b9a1c2f8 DxSpy!OpenFile+0x4d2
b9a1c35c b97f9c3f b9811c38 897cb020 89844d70
DxSpy!CreateDispatchFilter+0x63b
b9a1c4c0 b980414a 897cb020 89844d70 884de9d8
DxSpy!CreateDispatchCallback+0x6ff
b9a1c52c b9808700 89d25a08 89844d70 00000000 DxSpy!FilterCreateDispatch+0xea
b9a1c584 80840153 89d25a08 89844d70 89844d70 DxSpy!MajorCreate+0x220
b9a1c598 8092e806 b9a1c740 8a2ee8d8 00000000 nt!IofCallDriver+0x45
b9a1c680 8092c37a 8a2ee8f0 00000000 893bdad0 nt!IopParseDevice+0xa35
b9a1c700 8092d79b 00000000 b9a1c740 00000240 nt!ObpLookupObjectName+0x5b0
b9a1c754 8092c65d 00000000 00000000 00000000 nt!ObOpenObjectByName+0xea
b9a1c7d0 808c1020 8803a050 00100000 b9a1c868 nt!IopCreateFile+0x447
b9a1c818 f7332a94 8803a050 00100000 b9a1c868
nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b9a1c8c0 f73331bb 00000000 00000000 0000005b
fltmgr!FltpExpandFilePathWorker+0x118
b9a1c8d8 f73332ff 8803a008 890244a4 8803a008 fltmgr!FltpExpandFilePath+0x19
b9a1c8f4 f733398b 8803a008 890244a4 000000fe
fltmgr!FltpGetNormalizedFileNameWorker+0x5f
b9a1c90c f73310bc 8803a008 890244a4 8803a008
fltmgr!FltpGetNormalizedFileName+0x19
b9a1c924 f7320610 808a5180 00000001 00000000
fltmgr!FltpCreateFileNameInformation+0x84
b9a1c940 f7320774 883d1ce8 890244ac 00000000
fltmgr!HandleStreamListNotSupported+0xfc
b9a1c96c f7320c94 c00000bb b9a1c9dc b9a1c9d8
fltmgr!FltpGetFileNameInformation+0xe8
b9a1c994 b9a3f6b8 000244ac 00000401 b9a1c9dc
fltmgr!FltGetFileNameInformation+0x114
b9a1c9b8 b9a4059a b9a1c9d8 890244ac b9a1ca54 QFAPFlt+0x56b8
b9a1ca34 f731c4ca 890244ac b9a1ca54 b9a1ca70 QFAPFlt+0x659a
b9a1ca94 f731df2a 00a1cad8 89024450 86b26fdc
fltmgr!FltpPerformPreCallbacks+0x2d4
b9a1caa8 f732c0ad b9a1cad8 f732a540 00000000
fltmgr!FltpPassThroughInternal+0x32
b9a1cac0 f732c5cc b9a1cad8 8763ada8 8867e2b8 fltmgr!FltpCreateInternal+0x63
b9a1caf4 80840153 897cb020 86b26d98 8a1b3638 fltmgr!FltpCreate+0x258
b9a1cb08 b98009a2 8867e2b8 8a1b3638 8763ada8 nt!IofCallDriver+0x45
b9a1cc44 b97f821b 8867e2b8 897cb020 b9a1cd2c DxSpy!OpenFile+0x4d2
b9a1cd90 b97f9c3f b9811c38 897cb020 88c2d568
DxSpy!CreateDispatchFilter+0x63b
b9a1cef4 b980414a 897cb020 88c2d568 8867e2b8
DxSpy!CreateDispatchCallback+0x6ff
b9a1cf60 b9808700 89d25a08 88c2d568 00000000 DxSpy!FilterCreateDispatch+0xea
b9a1cfb8 80840153 89d25a08 88c2d568 88c2d568 DxSpy!MajorCreate+0x220
b9a1cfcc 8092e806 b9a1d174 8a2ee8d8 00000000 nt!IofCallDriver+0x45
b9a1d0b4 8092c37a 8a2ee8f0 00000000 88c054c8 nt!IopParseDevice+0xa35
Thanks
Ashish
On Thu, Sep 24, 2009 at 8:50 PM, Alexandru Carp <
xxxxx@microsoft.com> wrote:
Having two or more filter manager devices on a stack is perfectly normal
(
http://blogs.msdn.com/alexcarp/archive/2009/06/09/filter-manager-concepts-part-1-fltp-frame.aspx
).Could you please post a stack ?
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I’m not sure why your filter appears twice in this stack, but regardless it seems you use more than 1k of stack every time which is a lot. You might want to look into that.
Also, if you are writing a new filter, you should consider a minifilter. That also help with many things including stack usage.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
The IRP_MJ_CREATE you build goes from your legacy filter to the Filter Manager instance, which sends it to the QFAPFlt minifilter. QFAOFkt calls FltGetFileNameInformation which ultimately calls into fltmgr!FltpExpandFilePathWorker.
The reason why your filter appears twice on the stack is because FltpExpandFilePathWorker calls IoCreateFileSpecifyDeviceObjectHint which will results in a recursive IRP_MJ_CREATE. This may sound counterintuitive given the fact that IoCreateFileSpecifyDeviceObjectHint is usually used to avoid recursion, but the truth is that Filter Manager calls it with the DeviceObject parameter set to NULL, so the IRP_MJ_CREATE is sent to the top of the stack, thus going back through your legacy filter.
From your stack text I suspect your OS is pre-Vista (XP or Server 2003), since fltpExpandFilePathWorker uses IoCreateFileEx instead of IoCreateFileSpecifyDeviceObjectHint on Vista and later versions of the OS.
However, I can’t figure out why you get a stack overflow. Can you post the full !analyze -v data?
Razvan
Thanks Razvan…This (Stack Trace) is the output from analyze -v. If you look
the bottom and top entry then it is almost 12kb which is Kernel Stack Size.
Yes…It is on windows 2003 SP2 it looks that QFAOFkt calls NORMALIZED
name…I read some where that minifilter should use FLT_FILE_NAME_OPENED to
avoid this type of problem…Any comments?
What are the pros and cons of getting Normalized name…
Also, is there anyway we can “check” this re-entrancy?
Thanks
Ashish
From the stack, it looks that
On Thu, Sep 24, 2009 at 11:18 PM, Razvan Hobeanu
wrote:
> The IRP_MJ_CREATE you build goes from your legacy filter to the Filter
> Manager instance, which sends it to the QFAPFlt minifilter. QFAOFkt calls
> FltGetFileNameInformation which ultimately calls into
> fltmgr!FltpExpandFilePathWorker.
>
> The reason why your filter appears twice on the stack is because
> FltpExpandFilePathWorker calls IoCreateFileSpecifyDeviceObjectHint which
> will results in a recursive IRP_MJ_CREATE. This may sound counterintuitive
> given the fact that IoCreateFileSpecifyDeviceObjectHint is usually used to
> avoid recursion, but the truth is that Filter Manager calls it with the
> DeviceObject parameter set to NULL, so the IRP_MJ_CREATE is sent to the top
> of the stack, thus going back through your legacy filter.
>
> From your stack text I suspect your OS is pre-Vista (XP or Server 2003),
> since fltpExpandFilePathWorker uses IoCreateFileEx instead of
> IoCreateFileSpecifyDeviceObjectHint on Vista and later versions of the OS.
>
> However, I can’t figure out why you get a stack overflow. Can you post the
> full !analyze -v data?
>
> Razvan
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>
> Also, is there anyway we can “check” this
re-entrancy?
?
On pre-Vista I’ve seen Filter Manager uses extended attributes in the create (look for irpSp->Parameters.Create.EaLength being non-zero) to recognize its recursive create (performed by IoCreateFileSpecifyDeviceObjectHint). However, you will have to dig in for the specific bytes it passes in EaBuffer if you want to recognize it. Please note that I never done this in code, it’s just a theory I developed while analyzing recursive creates from Filter Manager.
On Vista and later I saw it changed from extended attributes to using ECPs (Extra Create Parameters). Here again you’ll have to dig in for the specific EcpType GUID to pass into FsRtlFindExtraCreateParameter in order to retrieve the correct ECP. Again, this is just a theory based on observed behavior.
Alex, please correct me if the behavior I described is wrong.
However, I don’t know exactly how detecting the recursive create will help you in this case. As Alex said, since your main problem here appears to be stack usage, you might consider ways to reduce it or switching to a minifilter. IIRC one of the main reasons why Filter Manager has been developed in the first place was to deal with the increasing stack usage due to the increasing number of filters on the stack.
Razvan
>Is there any specific reason for that.
Different minifilter altitudes, some are lower then McAfee some are not.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi Razvan,
Nope, you are correct. EAs are used pre-Vista and ECPs in Vista and newer. However, I wouldn’t attempt to solve this by detecting this reentrancy as it will create more problems that it will solve. In this very particular case it would work, but if there is another filter manager frame above your filter you may find these tags on operations that you should not ignore.
In this case I stand by my original suggestion of moving to a minifilter or if that’s not possible at least reducing memory footprint in the create path.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.