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/
Context: I'm a Windows kernel driver newbie trying to use KMDF to build a filter driver, specifically to intercept a specific
IOCTL_KS_PROPERTY request on an audio driver stack. My understanding is that KS involves lots of
METHOD_NEITHER IOCTLs (including the one I'm interested in), hence this question.
According to MSDN, handling "neither" I/O in KMDF is somewhat subtle. The documentation describes in detail how to do it assuming that my driver wants to handle the request itself. But what if I simply want to forward it down to the next driver down the stack? The documentation doesn't mention that case.
I looked at various samples, including the toaster filter sample and OSR's very own GenFilter sample. In both cases,
IoDeviceControl requests are simply forwarded in the usual KMDF way with no special consideration given to potential
I don't understand how that approach could possibly be correct.
EvtIoDeviceControl runs in arbitrary thread context. By the time that request handler is called, the original thread context might already be gone, and attempts to forward the request as-is to the next driver down the stack might just result in that driver accessing an invalid buffer.
This brings me to the conclusion that any filter driver that implements
EvtIoDeviceControl and could potentially be confronted with
METHOD_NEITHER IOCTLs (including ones it might not know exist!) has to implement an
EvtIoInCallerContext callback and go through the whole process of locking the user buffer. (As a side note I'm not sure I understand why KMDF can't do that automatically…) One example of that process is the
NONPNP sample, but note that is not a filter driver.
So let's say I implement
EvtIoInCallerContext and go through this whole dance. Then I want to forward the request to the next-lower driver. But wait, I can't simply use
WdfRequestFormatRequestUsingCurrentType and call it a day, can I? I would still be forwarding the original user buffer which might not be usable. So… what now? Do I swap the buffer before forwarding the request, so that the I/O target gets my buffer obtained from
Given this rabbit hole I find myself into and my complete lack of experience, I am starting to doubt myself. Am I overthinking all this and trying to solve a problem that doesn't exist? Am I missing something here?
|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!|
|Internals & Software Drivers||7 February 2022||Live, Online|
|Kernel Debugging||21 March 2022||Live, Online|
|Developing Minifilters||23 May 2022||Live, Online|
|Writing WDF Drivers||12 September 2022||Live, Online|