Hi,
When I call FltGetFileNameInformation() to get the normalized name,
IoCreateFileSpecifyDeviceObjectHint() is called with NULL device object but
I think it should be called with FileSystem device object to avoid
recursion.
Is it a bug or it is just that for Normalized Name, the request has to
be send to top of the stack instead of sending it down ?
The OS is windows 2003.
b9d48598 8092e806 b9d48740 8a316018 00000000 nt!IofCallDriver+0x45
b9d48680 8092c37a 8a316030 00000000 89527c28 nt!IopParseDevice+0xa35
b9d48700 8092d79b 00000000 b9d48740 00000240 nt!ObpLookupObjectName+0x5b0
b9d48754 8092c65d 00000000 00000000 00000000 nt!ObOpenObjectByName+0xea
b9d487d0 808c1020 878d1450 00100000 b9d48868 nt!IopCreateFile+0x447
b9d48818 f7332a94 878d1450 00100000 b9d48868
nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b9d488c0 f73331bb 00000000 00000000 0000007c
fltmgr!FltpExpandFilePathWorker+0x118
b9d488d8 f73332ff 878d1408 86545a24 878d1408 fltmgr!FltpExpandFilePath+0x19
b9d488f4 f733398b 878d1408 86545a24 000000fe
fltmgr!FltpGetNormalizedFileNameWorker+0x5f
b9d4890c f73310bc 878d1408 86545a24 878d1408
fltmgr!FltpGetNormalizedFileName+0x19
b9d48924 f7320610 808a5180 00000001 00000000
fltmgr!FltpCreateFileNameInformation+0x84
b9d48940 f7320774 85bdcda8 86545a2c 00000000
fltmgr!HandleStreamListNotSupported+0xfc
b9d4896c f7320c94 c00000bb b9d489dc b9d489d8
fltmgr!FltpGetFileNameInformation+0xe8
b9d48994 b94de6b8 00545a2c 00000401 b9d489dc
fltmgr!FltGetFileNameInformation+0x114
b9d489b8 b94df59a b9d489d8 86545a2c b9d48a54 MyDriver+0x56b8
b9d48a34 f731c4ca 86545a2c b9d48a54 b9d48a70 MyDriver+0x659a
This is by design. The idea was that the IO needs to go to the top of the stack so that mount points and such are resolved… This is a questionable solution but it’s the way it is.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
Alex,
I am not sure if there is any IO going here. I am just asking for
Normalized filename and I believe this cannot be considered as IO. Also, I
am not sure how this will avoid re-entrancy…I thought Filter Manager was
designed to avoid re-entrancy.
Thanks
Ashish
On Fri, Oct 9, 2009 at 6:42 PM, Alexandru Carp > wrote:
> This is by design. The idea was that the IO needs to go to the top of the
> stack so that mount points and such are resolved… This is a questionable
> solution but it?s the way it is.
>
>
>
> 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/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Hello Ashish,
In most cases asking for a normalized names requires talking to the file system, so therefore you have some IO. However, IO of this type will not be seen by minifilters that are not name providers. I wrote a bit more about this here (not specifically about this issue but there is some info about name providers in general): http://blogs.msdn.com/alexcarp/archive/2009/10/08/verifier-checks-a-filter-has-completed-an-operation-but-does-not-implement-name-provider-callbacks.aspx
However, filter manager detects this re-entracy itself and it won’t show this IO to minifilters that are not name providers, so most minifilters don’t need to worry about this re-entrancy. Are you seeing any issues in particular ?
Thanks,
Alex.
Alex,
With the combination of Legacy filter we are having crash…Legacy
filter send a Create IRP to open the file for reading Attrbutes, in turn
we call filter manager to get the normalized name and filter manager sends
IRP to legacy driver since this is at top. So we have kernel Stack Overflow
due to recursion.
I am not sure if this problem is with every Legacy Filter driver? Does
filter driver require some special coding to handle this case…Is this
re-entrancy issue.
Thanks
Ashish
On Sat, Oct 10, 2009 at 11:43 PM, Alexandru Carp <
xxxxx@microsoft.com> wrote:
Hello Ashish,
In most cases asking for a normalized names requires talking to the file
system, so therefore you have some IO. However, IO of this type will not be
seen by minifilters that are not name providers. I wrote a bit more about
this here (not specifically about this issue but there is some info about
name providers in general):
http://blogs.msdn.com/alexcarp/archive/2009/10/08/verifier-checks-a-filter-has-completed-an-operation-but-does-not-implement-name-provider-callbacks.aspx
However, filter manager detects this re-entracy itself and it won’t show
this IO to minifilters that are not name providers, so most
minifilters don’t need to worry about this re-entrancy. Are you seeing any
issues in particular ?
Thanks,
Alex.
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
So you are trying to get the normalized name from a legacy filter ? That is not a supported scenario. If you are a legacy filter you should build your own name resolution routines.
Thanks,
Alex.
Alex,
Sorry for confusion…We have a legacy driver which is topmost…In Create
operation Legacy driver do another IRP_MJ_CREATE to open new stream on
current FileObject. This is to perform QUERY_INFORMATION before allowing
first Create operation to proceed. This second Create operation comes to us
(mini-filter) and we call Filter manager to get NORMALIZED name but that is
routed back to topmost Legacy driver and which is turn creates another
Create request and so on…
Hope it would be clear now…
Thanks
Ashish
On Sun, Oct 11, 2009 at 11:26 AM, Alexandru Carp <
xxxxx@microsoft.com> wrote:
So you are trying to get the normalized name from a legacy filter ? That
is not a supported scenario. If you are a legacy filter you should build
your own name resolution routines.
Thanks,
Alex.
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
You need to handle re-entrant recursion from other filters such at fltmgr
in your IFS filter. Fltmgr introduced such recursion in a wide spread
manner when it implemented name normalization. So just part of the job
unfortunately.
t.
On Sun, 11 Oct 2009, Ashish Goyal wrote:
Alex,
Sorry for confusion…We have a legacy driver which is topmost…In Create
operation Legacy driver do another IRP_MJ_CREATE to open new stream on
current FileObject. This is to perform QUERY_INFORMATION before allowing
first Create operation to proceed. This second Create operation comes to us
(mini-filter) and we call Filter manager to get NORMALIZED name but that is
routed back to topmost Legacy driver and which is turn creates another
Create request and so on…
Hope it would be clear now…
Thanks
Ashish
On Sun, Oct 11, 2009 at 11:26 AM, Alexandru Carp <
xxxxx@microsoft.com> wrote:
> So you are trying to get the normalized name from a legacy filter ? That
> is not a supported scenario. If you are a legacy filter you should build
> your own name resolution routines.
>
> Thanks,
> Alex.
>
>
> —
> 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
>
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