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

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:


benjibenji Member Posts: 5
edited January 20 in NTFSD


I'm facing a weird problem and need some help to understand what I'm doing wrong (if so).

I have a minifilter that does FileObject hooking/breaking, it intercepts request from above and creates new requests (with new FileObjects) to below minifilters. It records the matching between the upper FileObject and the created FileObject that goes below.

I had some BSODs because my filter didn't implement the PFLT_GENERATE_FILE_NAME callback and replace the CallbackData->Iopb->TargetFileObject. So the file system (and minifilters below me) were receiving unknown file objects and then it led to BSODs.

I implemented the PFLT_GENERATE_FILE_NAME callback and hooked/replaced its CallbackData->Iopb->TargetFileObject (and called FltSetCallbackDataDirty()) in order to have mini filters below me receive a FileObject they know (so it doesn't BSOD).

But I'm altering the CallbackData of an ongoing IRP. When the PFLT_GENERATE_FILE_NAME callback is over and the minifilter (above me) that invoked it has the information it wanted, it has a modified TargetFileObject. So this minifilter and all the minifilters until mine will see a TargetFileObject they aren't supposed to see.

Am I missing something in the documentation? They is no "post callback"/mechanism so that I can put back the TargetFileObject.

Is someone able to tell me where I'm wrong?

If something isn't clear in my explanations don't hesitate to ask me to reformulate or for more informations.

Thank you.


  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,131

    I don't k now the answer to your question, but for my money the definitive documentation for name provider callback is Alex's Blog which sort of indicates that you cannot change the parameterization on the fly.

  • benjibenji Member Posts: 5

    I read a lot of his articles, they are very good!
    If I can't change them, then this means I cannot do file object hooking ... :/ ?

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,299

    You need to satisfy the request yourself instead of letting it flow through the filter stack (as Rod said see Alex's example). This allows you to change the arguments, make the necessary calls to satisfy the request, and then put the arguments back before returning to Filter Manager. For example, something like this in the name generation callback:

            originalFileObject = CallbackData->Iopb->TargetFileObject;
            CallbackData->Iopb->TargetFileObject = targetFileObject;
            status = FltGetFileNameInformation(CallbackData,
            CallbackData->Iopb->TargetFileObject = originalFileObject;


  • benjibenji Member Posts: 5

    Yes, after re-reading my code I saw the obvious mistake :) I just need to put it back.
    Thank both of you for your time.

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!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA