attach filter to umdf driver

what I’m working is to modify the data of sensors,
as far as I know, the most efficient way is attaching the filter driver to the target device,
but regardless of kmdf or umdf filter doesn’t work for the sensor hid class driver(the device failed to be started).
so my question is whether it is possible to do what I need by this way? or there is other better way?

I guess the biggest problem for me is not on the right way to install the kmdf upper filter,
what I did is manually adding a UpperFilters registry value with my upper filter driver’s service name in the sensor class driver key,
and I actually saw my filter be loaded, but the device showed code 10…

I’ve reviewed many threads about this question such as venerable Tim’s post at 2013
http://www.osronline.com/showthread.cfm?link=251699

but I still don’t know how to legally install a standalone kmdf upper filter for the MSFT’s in-box driver, or is there any direct sample in wdk?
Currently, I’m based on win10’s toaster generic filter sample.

Thanks in advanced

xxxxx@hotmail.com wrote:

I guess the biggest problem for me is not on the right way to install the kmdf upper filter,
what I did is manually adding a UpperFilters registry value with my upper filter driver’s service name in the sensor class driver key,
and I actually saw my filter be loaded, but the device showed code 10…

I’ve reviewed many threads about this question such as venerable Tim’s post at 2013
http://www.osronline.com/showthread.cfm?link=251699

but I still don’t know how to legally install a standalone kmdf upper filter for the MSFT’s in-box driver, or is there any direct sample in wdk?

Well, that post was the opposite situation: trying to crowbar a UMDF
filter into a kernel-mode stack.

You need to remember that there is a fair amount of overhead when you
make that user/kernel transition. Calling into a UMDF driver means not
only switching back to user mode, but doing a context switch to the UMDF
user-mode process. You want to avoid going back and forth.

Because of that, Microsoft does not allow there to be a kernel driver on
top of a UMDF driver, unless the UMDF driver allows it. There is a
magic registry entry that says “it’s OK to have a kernel driver on top
of me”. Depending on the version, it’s either UpperDriverOk or
UmdfKernelModeClientPolicy. If you don’t own the UMDF driver, then
there is a certain amount of danger in hacking that value, but that’s
what it takes.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks, Tim.

I’ve tried to manually put the UmdfKernelModeClientPolicy registry for sensor hid class driver,
but it still gave me a code 10 as well lol, so the driver doesn’t allow kmdf filter to interact with itself,
therefore, I turn to try umdf filter again, and it finally works, there was something wrong with my umdf filter INF.

Now I have another problem is that I literally don’t know how to catch the HID usage table of sensor data by my umdf filter, do you have any suggestions?

Thanks in advanced.

What do you mean catch? Get the hid descriptor?

Get Outlook for Android

From: xxxxx@lists.osr.com on behalf of xxxxx@hotmail.com
Sent: Friday, November 25, 2016 1:04:02 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] attach filter to umdf driver

Thanks, Tim.

I’ve tried to manually put the UmdfKernelModeClientPolicy registry for sensor hid class driver,
but it still gave me a code 10 as well lol, so the driver doesn’t allow kmdf filter to interact with itself,
therefore, I turn to try umdf filter again, and it finally works, there was something wrong with my umdf filter INF.

Now I have another problem is that I literally don’t know how to catch the HID usage table of sensor data by my umdf filter, do you have any suggestions?

Thanks in advanced.

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Hi Doron,

yup, get and analyze the hid descriptor for sensors, then furthermore modify it.
Is there a similar sample that demonstrate such things?

Thanks.

You want a lower filter below the sensor driver as the upper edge will not “speak” hid. I don’t know if a umdf lower filter will see the hid io requests sent by the FDo though. Modifying hid descriptors at this layer requires you to change each sent io request to match what hidclass expects as it knows only the original descriptor.

If you want hidclass to see a different hid descriptor you need to filter below the hidclass mini port

Get Outlook for Android

From: xxxxx@lists.osr.com on behalf of xxxxx@hotmail.com
Sent: Friday, November 25, 2016 5:49:43 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] attach filter to umdf driver

Hi Doron,

yup, get and analyze the hid descriptor for sensors, then furthermore modify it.
Is there a similar sample that demonstrate such things?

Thanks.

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Hi Doron,

Sorry for the wrong statement before,
I’m not going to change the HID descriptor for the sensors, I’m just going to modify the sensor’s data on the fly.
What’s the right path to do that as my sensors are reported as a vendor-defined HID device that loaded MSFT inbox driver?

Thanks in advanced

@Tim_Roberts said:
You need to remember that there is a fair amount of overhead when you
make that user/kernel transition. Calling into a UMDF driver means not
only switching back to user mode, but doing a context switch to the UMDF
user-mode process. You want to avoid going back and forth.

Because of that, Microsoft does not allow there to be a kernel driver on
top of a UMDF driver, unless the UMDF driver allows it. There is a
magic registry entry that says “it’s OK to have a kernel driver on top
of me”. Depending on the version, it’s either UpperDriverOk or
UmdfKernelModeClientPolicy. If you don’t own the UMDF driver, then
there is a certain amount of danger in hacking that value, but that’s
what it takes.

This MS doc says that it’s only supposed to work for UMDF below 1.9: https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/supporting-kernel-mode-clients-in-umdf-1-x-drivers#kernel-mode-client-support-in-earlier-umdf-versions (“For UMDF versions earlier than version 1.9, a driver’s INF file can include an INF AddReg directive to create a REG_DWORD-sized UpperDriverOk registry value under the WUDF subkey of the device’s hardware key.”).
We’ve tried quite a few tests while manually enabling KMDF filtering via INF installation but not sure whether the registry option would work. Is there a more specific description when it may be used or not?

Also, is it correct that the magic value UpperDriverOk (which actual UMDF version requires UmdfKernelModeClientPolicy?) should go under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WUDF\Services\TARGET_DRIVER_NAME

Thanks!

Following up a four year old post?

Please start a new thread, per the rules.

Thanks,

Peter