FltMgr name resolution and the FSD stack

NTFSD
1

When FltMgr needs to get the normalized file name, is there any
reason it would send create requests to the top of the stack instead of
only to the underlying filters?

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

2

Hi Dejan,

As far as I know FltMgr shouldn’t ever send request to the top. Are you
seeing something else ?

Thanks,
Alex.

3

I am currently working on a problem from a customer where a filter below my
filter is sending a request to the top when I make a name resolution call.
In my case the end result is running out of stack because of the resulting
recursion.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alex Carp
Sent: Friday, February 04, 2011 5:44 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltMgr name resolution and the FSD stack

Hi Dejan,

As far as I know FltMgr shouldn’t ever send request to the top. Are you
seeing something else ?

Thanks,
Alex.

NTFSD is sponsored by OSR

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

4

But is the filter below yours a legacy filter? Or is this FltMgr sending the
request to the top ?

Thanks,
Alex.

5

It was not FltMgr. It was the filter that was sending the requests. I need
to go back to the dump. I actually haven’t looked at it in some time but my
next task is to get back to it. The customer has uninstalled the product
that caused the recursion so the priority is not critical (yet).

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alex Carp
Sent: Friday, February 04, 2011 6:34 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltMgr name resolution and the FSD stack

But is the filter below yours a legacy filter? Or is this FltMgr sending the
request to the top ?

Thanks,
Alex.

NTFSD is sponsored by OSR

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

6

That seems to be what is happening. With a certain third party filter, when FltMgr receives a
FastIoQueryBasicInfo, our filter does not have a context for that file yet (more below), and calls
FltgetFileNameInformation, which sends the request to the top of the stack (the third party filter is on top, on
Lanman, while on other volumes FltMgr is on top).

Why our filter does not have a context yet is also peculiar, as the file should already have been opened, and
the FastIoQueryBasicInfo call is a result of the third part filter doing a query in its post-create. (the third
party filter is a legacy, not mini filter).

Dejan.

Alex Carp wrote:

Hi Dejan,

As far as I know FltMgr shouldn’t ever send request to the top. Are you
seeing something else ?

Thanks,
Alex.

NTFSD is sponsored by OSR

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

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

7

That would also happen in our case, however, when FltMgr detects it is running out of stack, it posts the
request instead.

Bill Wandel wrote:

I am currently working on a problem from a customer where a filter below my
filter is sending a request to the top when I make a name resolution call.
In my case the end result is running out of stack because of the resulting
recursion.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alex Carp
Sent: Friday, February 04, 2011 5:44 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltMgr name resolution and the FSD stack

Hi Dejan,

As far as I know FltMgr shouldn’t ever send request to the top. Are you
seeing something else ?

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

8

> As far as I know FltMgr shouldn’t ever send request to the

top. Are you seeing something else ?

I recall that this is a known bug with FltMgr. In the case of queries for normalized names, FltMgr can generate a call to the top of the stack.

There is an older thread where an instance of this issue has been discussed. FltMgr was calling IoCreateFileSpecifyDeviceObjectHint which resulted in a recursive IRP_MJ_CREATE because the FltMgr passed NULL for the DeviceObject parameter of IoCreateFileSpecifyDeviceObjectHint.

The OP of that thread was seeing a stack overflow due to the FltMgr causing the recursive calls into his filter.

Here is the link to the thread:

“Filter Manager Loading” - 24 Sep 2009
https://www.osronline.com/ShowThread.cfm?link=166553

Regards,
Razvan

9

I thought this problem was only in the case where the filter attempting
to retrieve a normalized name was also a name provider? As long as you
don’t specify the flag (FLT_FILE_NAME_REQUEST_FROM_CURRENT_PROVIDER)
indicating to call the current filters name provider routines, then all
was OK. I would need to go back but I recall a restriction on specify
FLT_FILE_NAME_NORMALIZED.

Pete

On 2/5/2011 12:20 PM, Razvan Hobeanu wrote:

> As far as I know FltMgr shouldn’t ever send request to the
> top. Are you seeing something else ?

I recall that this is a known bug with FltMgr. In the case of queries for normalized names, FltMgr can generate a call to the top of the stack.

There is an older thread where an instance of this issue has been discussed. FltMgr was calling IoCreateFileSpecifyDeviceObjectHint which resulted in a recursive IRP_MJ_CREATE because the FltMgr passed NULL for the DeviceObject parameter of IoCreateFileSpecifyDeviceObjectHint.

The OP of that thread was seeing a stack overflow due to the FltMgr causing the recursive calls into his filter.

Here is the link to the thread:

“Filter Manager Loading” - 24 Sep 2009
https://www.osronline.com/ShowThread.cfm?link=166553

Regards,
Razvan

NTFSD is sponsored by OSR

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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

10

Hi Peter,

I think that that’s a different issue. IIRC, if you use both
FLT_FILE_NAME_NORMALIZED and FLT_FILE_NAME_REQUEST_FROM_CURRENT_PROVIDER,
then your filter might be called to normalize the name for each component on
the path, in a recursive fashion, so it would potentially use a lot of stack
for paths with very long components… I think we were talking about
something along these lines a couple of plugfets ago, but perhaps you also
saw a different issue ?

Thanks,
Alex.

11

" That seems to be what is happening. With a certain third party filter,
when FltMgr receives a FastIoQueryBasicInfo, our filter does not have a
context for that file yet (more below), and calls FltgetFileNameInformation,
which sends the request to the top of the stack (the third party filter is
on top, on Lanman, while on other volumes FltMgr is on top).

Why our filter does not have a context yet is also peculiar, as the file
should already have been opened, and the FastIoQueryBasicInfo call is a
result of the third part filter doing a query in its post-create. (the third
party filter is a legacy, not mini filter)."

This is interesting and might explain some things. Once an IRP_MJ_CREATE is
successfully completed, the targeting information that FLtMgr keeps (which
identifies which instance issues the create so that it can layer it
properly… that is what’s stored in the ECP or the EA (pre-Vista)) is moved
to a context that is associated with the FILE_OBJECT (the equivalent of a
StreamHandle context). If for whatever reason the context is messed up in
some way, then it is possible that both the targeting information and the
contexts would be missing …

Which OS is this happening on ?

Thanks,
Alex.

12

This is on every OS, we made sure it also happens on W7 as means of assuring it was not already fixed in some
QFE/other.

Dejan.

Alex Carp wrote:

" That seems to be what is happening. With a certain third party filter,
when FltMgr receives a FastIoQueryBasicInfo, our filter does not have a
context for that file yet (more below), and calls FltgetFileNameInformation,
which sends the request to the top of the stack (the third party filter is
on top, on Lanman, while on other volumes FltMgr is on top).

Why our filter does not have a context yet is also peculiar, as the file
should already have been opened, and the FastIoQueryBasicInfo call is a
result of the third part filter doing a query in its post-create. (the third
party filter is a legacy, not mini filter)."

This is interesting and might explain some things. Once an IRP_MJ_CREATE is
successfully completed, the targeting information that FLtMgr keeps (which
identifies which instance issues the create so that it can layer it
properly… that is what’s stored in the ECP or the EA (pre-Vista)) is moved
to a context that is associated with the FILE_OBJECT (the equivalent of a
StreamHandle context). If for whatever reason the context is messed up in
some way, then it is possible that both the targeting information and the
contexts would be missing …

Which OS is this happening on ?

Thanks,
Alex.

NTFSD is sponsored by OSR

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

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

13

For the benefit of the archive, I’ve done a bit more research and FltMgr
does send IO to the top of the stack in fltmgr!FltpExpandFilePathWorker.

Thanks,
Alex.