UPDATED: 9-March-2010 Astute readers noted that I had the incorrect driver load order when talking about the UmdfServiceOrder directive. 🙂 It IS left to right reading and the LEFT most driver is the lowest driver.
In my previous post about Filter Drivers, I mentioned that this time I would focus on a more UMDF centric stack. This one is pretty simple.
For UMDF only based driver stacks, the single most important directive is the UmdfServiceOrder INF directvie. As I mentioned last post, that directive is a left to right list determining load order for the drivers contained in the device stack. With the left most element in that list being the the lowest driver loaded.
Here are two examples – First a UMDF two driver stack with an upper filter;
Now to install a lower filter, simply flip the order in that directive;
The last tidbits here are; for a device stack that only contains UMDF drivers, there is no need to add any of these settings in the INF;
; Load the redirector as an upperfilter on this specific device.
; 0x00010008 – FLG_ADDREG_TYPE_MULTI_SZ | FLG_ADDREG_APPEND
And also as before, the filter driver needs to be a good citizen on the stack, pass on requests it does not own to the next driver and don’t touch anything unless you must. The previous code samples I’ve posted all still apply, but the basics are; GetDefaultIoTarget, FormatUsingCurrentType and Send.
There’s no need to change any code for a basic filter driver based on its load order (upper or lower filter). As you get in to more advanced driver functionality you may find a need to change default behaviors. For those cases, you can always send us mail. 🙂
There was also some questions about why would you want or need to be an upper or lower filter driver. That one gets in to a bit more of a “it’s up to you” but the core logic that applies to WDM / KMDF drivers applies to UMDF drivers (save the parts about bus drivers *g*).