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

Home NTFSD

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/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Null EXTENSION in PFLT_FILE_NAME_INFORMATION from FltGetFileNameInformation in MJ_CREATE preop

AlorynnAlorynn Member Posts: 13

I'm writing a minifilter which has several functions, one of which is identifying files for processing based on extension. In the interests of time I tried using FltGetFileNameInformation like so:

PFLT_FILE_NAME_INFORMATION userFileNameInfo = NULL;

if (ARGUMENT_PRESENT( Data )) {

            status = FltGetFileNameInformation( Data,
                                                NameOptions,
                                                &userFileNameInfo );
        } else {
            status = FltGetFileNameInformationUnsafe( FileObject,
                                                      Instance,
                                                      NameOptions,
                                                      &userFileNameInfo );
        }

As taken from line 2505 in this Microsoft minifilter example, with code generated from the MS minifilter project wizard. In my case every file has a valid PFLT_CALLBACK_DATA so the else clause is never invoked, and while the PFLT_FILE_NAME_INFORMATION seems to have valid fields (including the filename showing the correct extension), the EXTENSION field is almost always null. For NAME_OPTIONS I've tried both of the following:

FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT
FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP

I fear I'm doing something wrong/dangerous since that EXTENSION field isn't being populated correctly so I thought I'd check with the experts before I proceed relying on my PFLT_FILE_NAME_INFORMATION. Thanks.

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,188

    You are probably missing a call to FltParseFileNameInformation

  • AlorynnAlorynn Member Posts: 13

    Ah that was it thanks - any idea why the extension field sometimes is populated correctly without running the parse function? That's what threw me initially, the mixed results.

    Incidentally I see from other OSR posts that this function can be quite heavy to invoke, is there a faster method I should be using?

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,188

    Ah that was it thanks - any idea why the extension field sometimes is populated correctly without running the parse function?

    These things are cached, so if someone had already done a lookup and parse...

    Incidentally I see from other OSR posts that this function can be quite heavy to invoke,

    Don't call it in pre-create. That hurts, otherwise if you need the name, you need the name. Remember it is cached. But a very common paradigm is to set up everything you need to know in postcreate and then you are done (modulo rename, and symbolic links)

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 430

    Actually the file name normalization is somewhat heavy in pre-create, but opened file name query is almost unnoticed (unless it is an open by file ID, the process is just some string parsing).

    Even name normalization in pre-create is not as big of a deal as it was when FltMgr first arrived (this is not FltMgr's fault, it just uses what is available). It used to be that we got a MAJOR performance boost for a system where we moved name normalization into post-create for FILE_OPEN processing (which is the vast majority of opens), on systems that had nothing to do with heavy file I/O, but it was really noticeable still.

    I have builds of my project that use ALWAYS_NORMALIZE, NORMALIZE_POST_CREATE_FOR_FILE_OPEN, NEVER_NORMALIZE_BUT_QUERY_PRE_CREATE and ONLY_POST_CREATE_OPENED_QUERY (those are actual #defines that tell the driver how to process names).
    The performance penalty of the first one on Windows 10 is barely traceable. It is not noticeable, it is just traceable (as in, we can see the difference only if we focus on a lot of IRP_MJ_CREATES in succession). The difference before (XP time) was extreme. I do not remember the exact times, I actually posted them on the forum back then... I think it was in the order of >100x difference, so we saw IRP_MJ_CREATEs that took milliseconds to finish! sometimes! (this is not just one IRP_MJ_CREATE, since we had AVs in the stack, and a performance monitoring driver until ProcMon, but the difference without them was still high)

    If someone finds my posts with the numbers, share back, please :)

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!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 2 August 2021 Live, Online
Kernel Debugging 27 Sept 2021 Live, Online