Hi folks,
Does anyone know why the “UmdfKernelModeClientPolicy” is missing from the WPDMPT.INF file on Windows Server 2008 SP2 and also on some Windows 7 setups?
This is keeping my filter driver from being correctly load on the device stack, and by the time the AddDevice dispatch comes in, it seems it’s too late to set the “KernelModeClientPolicy” registry value manually.
Any thoughts? Thanks in advance!
xxxxx@teleline.es wrote:
Does anyone know why the “UmdfKernelModeClientPolicy” is missing from the WPDMPT.INF file on Windows Server 2008 SP2 and also on some Windows 7 setups?
This is keeping my filter driver from being correctly load on the device stack, and by the time the AddDevice dispatch comes in, it seems it’s too late to set the “KernelModeClientPolicy” registry value manually.
There are performance implications in having a UMDF driver with a KMDF
filter on top of it. Every user/kernel transition takes many cycles.
Thus, it is not enabled by default. If you’re writing your own UMDF
driver, you can enable that ability for yourself in your own device stack.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim, thanks for the info.
My driver is a WDM class filter, which I use to monitor several device classes.
It’s working fine except for Portable Devices, that’s why I needed to enable that policy for every WPD device, is that feasible?
If this scenario (WDM upper filter on Portable Devices) is prone to problems, how could I achieve a reliable filtering?
Maybe by writing an UMDF class filter? I think I once read somewhere that it’s not possible to filter device classes with an UMDF driver, am I correct?
Thanks again!
On Jan 20, 2015, at 12:25 AM, xxxxx@teleline.es wrote:
Hi Tim, thanks for the info.
My driver is a WDM class filter, which I use to monitor several device classes.
Monitor them for what? What do these device classes have in common that you could be looking for?
It’s working fine except for Portable Devices, that’s why I needed to enable that policy for every WPD device, is that feasible?
In general, no. I suppose you could go hack the registry to turn on the “kernel filters OK” flag, but if there are drivers that assume that will never happen, disaster might result. (That seems very unlikely.)
If this scenario (WDM upper filter on Portable Devices) is prone to problems, how could I achieve a reliable filtering?
You can’t, not at that level.
Maybe by writing an UMDF class filter? I think I once read somewhere that it’s not possible to filter device classes with an UMDF driver, am I correct?
I assume you are aware that UMDF drivers work by inserting a thin kernel mode driver into the stack that proxies requests out to the user-mode client and responses back into the kernel, right? Even a UMDF driver has a kernel component.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Those classes don’t have anything in common, I’m just trying some approach for a finer control of devices…yeah, the usual security stuff.
However it’s pretty clear that this is not the way to go, at least with Portable Devices. I already noted that registry hack is just looking for disaster 
Thank you so much for the info, Tim.
Cheer!