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: https://www.osr.com/osr-learning-library/
Minifilter, replacing the name in FileObject when IRP_MJ_CREATE with FILE_OPEN_BY_FILE_ID
Rude_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:
FILE_ID_INFORMATION fileID;
...
status = FltQueryInformationFile(
FltObjects->Instance,
foReplacingFile,
&fileID,
sizeof(fileID),
FileIdInformation ,
NULL);
...
status = IoReplaceFileObjectName(FltObjects->FileObject, (PWCHAR)&fileID.File Id, sizeof(fileID.File Id));
Returning STATUS_REPARSE
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?
Howdy, Stranger!
| 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 |
Comments
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?
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