STATUS_PRIVILEGE_NOT_HELD while sending IOCTL_HID_GET_FEATURE from KMDF HID client

NTDEV
21

You have an additional alternative. You write an INF that installs the “null” driver on top of the device (it is a special directive in the INF, there is no physical null driver), essentially blocking out the sensor driver from matching against the device. With the null driver installed, it is a normal HID and you can access it with normal HID semantics and HID io

If you can give the special sensor that should not be exposed as a sensor its own unique hardware ID (compared to its peers which will be sensors who have a different hardware ID), yes it is easy to target on the special sensor. If you can’t, then you have to have magic in your installer that identifies the right sensor. Special magic in the installer only works for desktop or server, if you want to target phone or other Microsoft OS editions, you can’t do that. Even on desktop, special installer magic makes migration to a new OS very difficult and perhaps it does not replicate on the new OS.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.co.in
Sent: Tuesday, July 19, 2016 9:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] STATUS_PRIVILEGE_NOT_HELD while sending IOCTL_HID_GET_FEATURE from KMDF HID client

Thanks Again!

We do not need to expose this to the OS. The FW exposes this as a sensor device and currently we do not have the flexibility to change that. So if we do not load on this device the inbox UMDF driver is going claim it. In that scenario was evaluating the option of our KMDF ACPI driver to talk to the HID stack directly so that we have only one driver. The other option is the original one in this thread where we claim the device and talk to the ACPI driver via a private interface.

Technically there could be multiple instances of the sensor devices(only one of which would be the one I am interested in) exposed and correspondingly there would be that many instances of the inbox sensor driver. In such a scenario would it be possible to have this ACPI driver as a lower filter for just one particular instance of the inbox sensor driver?

Thanks
Sudheer

—
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:>

22

The null driver option seems promising. We do have the option of having a special ID for this device.

I assume if we have to sign the drivers eventually we will have to submit the null driver INF also in the package and it should be OK?

23

Yes

Get Outlook for Androidhttps:

On Tue, Jul 19, 2016 at 11:42 PM -0700, “xxxxx@yahoo.co.in” > wrote:

The null driver option seems promising. We do have the option of having a special ID for this device.

I assume if we have to sign the drivers eventually we will have to submit the null driver INF also in the package and it should be OK?

—
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:></https:>

24

I got the same problem. I fixed it by calling “WdfIoTargetSendInternalIoctlSynchronously()” for sending IOCTL_HID_GET_FEATURE.

25

@ginolin … I’m sure the OP will appreciate your advice, even if it is 6 years after he needed it.

People, people, people: CHECK THE DATE before you respond. Please?