Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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.Pre-op Post-op design
Hi,
Porting a legacy filter driver to a minifilter I encounter a design problem.
The legacy filter code could have many paths after an IoCallDriver() for an IRP_MJ_WRITE. Doing stuff on the VDL, making read/write, etc .
So I can't think of having one post-op for the WRITE and many switches that handle all these paths.
In legacy filters, when not altering and IRP, using IoCallDriver, we could submit it to the next driver easily. How can I mimic this with minifilter when I have a lot of differents path in my post-op ?
Idea 1 : using FltWriteFile() inside the pre-op and deal with all these cases in the pre-op ? (but when I don't alter the WRITE data this makes me use FltLockUserBuffer() and MmGetSystemAddressForMdlSafe() and it slow the system performances (I can't use FltWriteFileEx() because I need Windows 7 support, otherwise I could have just forwarded the userBuffer and the MDL)).
Idea 2 : use FltPerformSynchronousIo(), never did, MSDN discourages this.
Another question can FsRtlCopyWrite() substitute to FltWriteFile ? In which cases ?
Thank you.
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! | ||
| Developing Minifilters | 24 May 2021 | Live, Online |
| Writing WDF Drivers | 14 June 2021 | Live, Online |
| Internals & Software Drivers | 27 September 2021 | Live, Online |
| Kernel Debugging | TBD 2021 | Live, Online |
Comments
Hi,
Since I didn't get any answer I'll try something different.
Is there any way to forward the original request as is in the pre op, and then wait for the response without using the post op mechanism ?
Say I have a SetInformationFile coming I want to forward it to the next filter instance, and then wait for the response inside my pre-op. In legacy drivers we could wait for the response by sync with an event in the callback routine.
The perfect solution would be to be able to choose the post op routine inside the pre op (so I can have as many post op as I want) but that's not possible...