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:

Minifilter, replacing the name in FileObject when IRP_MJ_CREATE with FILE_OPEN_BY_FILE_ID

Rude_Childish_NameRude_Childish_Name Member Posts: 5

Hello everybody!
In my minifilter, when IRP_MJ_CREATE comes with the FILE_OPEN_BY_FILE_ID flag, I change the ID that is in Data->App - >TargetFileObject - >FileName to the ID of another file

I get the ID and replace the ID as follows:


status = FltQueryInformationFile(
    FileIdInformation ,
status = IoReplaceFileObjectName(FltObjects->FileObject, (PWCHAR)&fileID.File Id, sizeof(fileID.File Id));


Data->IoStatus.Information = IO_REPARSE;
Data->IoStatus.Status = STATUS_REPARSE;

In this case, the repeated irp does not come. In User Space, I get the error " ERROR_INVALID_NAME"

I tried to replace it with a name of the following type:
\??\Volume{e148406e-0000-0000-0000-402400000000}\<< FILE_ID >>

In this case, the irp comes again, the mini filter works without errors, but the User Space still has an error

At the same time, in the kernel, I can open a file using this ID

Has anyone run into a problem where there might be a bug?


  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 588

    You'd be surprised at how many issues reparsing can cause. Even MS's SymRep sample will fault in many Driver Verifier -> FltMgr checks (well, not the vanilla one, because it only checks a few simple files that are not used in any complicated way, but if you extend it a bit more files, it does).

    When you return REPARSE you have to include the volume in the file name. The IO manager does not know that you want to reparse to the same volume :)

    What I found to be actually work a lot better is to change the file name, and just pass down the create. This is also a lot faster, since the upper filters and IoMgr will not need to process the same open.

    I do not see any issue in your second approach, though. The only difference, from what I did during testing, was to use a nonpersistent device name, instead of a GUID based one, but that should not matter (e.g. \device\harddiskvolume2\).

    Are you sure the create succeeds? Seems like an obvious question, but often comes down to such.
    Is the status in your post-create a success code, when the new fileID call returns from the lower filters?

  • Rude_Childish_NameRude_Childish_Name Member Posts: 5

    Yes, thank you
    In my post callback, I open with the parameters specified in Data->iopb, but ntdevice name
    After fixing it, the version with volume id is now working

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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 16-20 October 2023 Live, Online
Developing Minifilters 13-17 November 2023 Live, Online
Internals & Software Drivers 4-8 Dec 2023 Live, Online
Writing WDF Drivers 10-14 July 2023 Live, Online