Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


FltGetFileNameInformation returns STATUS_NO_MORE_FILES (0x80000006)

yuval0x92yuval0x92 Member Posts: 5

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

Comments

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 374
    via Email
    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 ;) 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.
    >
  • yuval0x92yuval0x92 Member Posts: 5

    @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 ;) 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

    >

    1. 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

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 374
    via Email
    > 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.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE