FltGetFileNameInformation returns STATUS_NO_MORE_FILES (0x80000006)

Hi all,

I am trying to get the name of a file in my kernel minifilter driver. As a user, I perform the following:

  1. Start a new container
  2. access a file inside the container.

When I intercept the MJ_IRP_CREATE on the said file, I call the function FltGetFileNameInformation () which returns STATUS_NO_MORE_FILES.
I do not understand why.

Note:
If I’m calling FltGetFileNameInformation() again after receiving this error, everything works.

Thanks for your attention

  • Y

Check the name in FileObject->FileName when this occurs.
Unless there is something specific about containers causing the
problem, the only thing I can think of is the “wildcard bug” in FGFNI.

If there is a wildcard in the file name (which is not a valid file
name for open/create/overwrite obviously), FGFNI attempts to list the
directory with that wildcard :wink: Hence the possibility that
STATUS_NO_MORE_FILES is returned.
Though I would argue that STATUS_NO_SUCH_FILE would be the right error
here, it could be that some logic requeries and gets
STATUS_NO_MORE_FILES after the first query succeeded.

Why it does not fail on the second try, I have no clue! Are you
changing any parameters? Normalized vs. Opened/Short file name format
for example, the query method?

Get ProcMon to observe the stack, and preferably place your filter
ABOVE ProcMon by altitude (for testing obviously), so you can see the
output correctly.

Dejan.

Hi all,

I am trying to get the name of a file in my kernel minifilter driver. As a
user, I perform the following:

  1. Start a new container

  2. access a file inside the container.

When I intercept the MJ_IRP_CREATE on the said file, I call the function
FltGetFileNameInformation () which returns STATUS_NO_MORE_FILES.

I do not understand why.

Note:

If I’m calling FltGetFileNameInformation() again after receiving this error,
everything works.

@Dejan_Maksimovic said:
Check the name in FileObject->FileName when this occurs.
Unless there is something specific about containers causing the
problem, the only thing I can think of is the “wildcard bug” in FGFNI.

If there is a wildcard in the file name (which is not a valid file
name for open/create/overwrite obviously), FGFNI attempts to list the
directory with that wildcard :wink: Hence the possibility that
STATUS_NO_MORE_FILES is returned.
Though I would argue that STATUS_NO_SUCH_FILE would be the right error
here, it could be that some logic requeries and gets
STATUS_NO_MORE_FILES after the first query succeeded.

Why it does not fail on the second try, I have no clue! Are you
changing any parameters? Normalized vs. Opened/Short file name format
for example, the query method?

Get ProcMon to observe the stack, and preferably place your filter
ABOVE ProcMon by altitude (for testing obviously), so you can see the
output correctly.

Dejan.

Hi all,

I am trying to get the name of a file in my kernel minifilter driver. As a
user, I perform the following:

  1. Start a new container

  2. access a file inside the container.

When I intercept the MJ_IRP_CREATE on the said file, I call the function
FltGetFileNameInformation () which returns STATUS_NO_MORE_FILES.

I do not understand why.

Note:

If I’m calling FltGetFileNameInformation() again after receiving this error,
everything works.

I don’t use any wildcards, and do not modify any parameters between the first and the second calls.
Regarding FileObject->FileName, this is only valid in IRP_MJ_CREATE. I wish to have a generic solution.

Thanks,
Y

> I don’t use any wildcards, and do not modify any parameters between the

first and the second calls.

Regarding FileObject->FileName, this is only valid in IRP_MJ_CREATE. I wish
to have a generic solution.
You said you are checking this in IRP_MJ_CREATE. Let’s stick to
that situation, because FileName field is valid. Do check it.
STATUS_NO_MORE_FILES has no logic in any other case, as FltMgr
would have a valid FILE_OBJECT and can query the file name from the
file system (unless you say that it can only check the cache - in
which, this might be the error it returns, but it should
STATUS_FLT_CACHE_MISS - could be a bug).

Can you reproduce this 100% (or close to that)? Can you post a
specific repro case?

The ProcMon suggestion is your best bet. Please report back in either case.