Null EXTENSION in PFLT_FILE_NAME_INFORMATION from FltGetFileNameInformation in MJ_CREATE preop

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.

You are probably missing a call to FltParseFileNameInformation

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?

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)

1 Like

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 :slight_smile: