STATUS_PRIVILEGE_NOT_HELD while sending IOCTL_HID_GET_FEATURE from KMDF HID client

Hi Doron,

No, with the remote target the open is what fails with “STATUS_NO_DEVICE”. I do not get to the point of trying to send the IOCTL.
ntStatus = WdfIoTargetOpen(wdfIoTarget, &wdfIoTargetOpenParams);

I tried this from D0Exit which also had the same problem.

Would there be a better place to call this from (other than making an external IOCTL call to trigger this) ? I do not have any interrupts etc but would providing a EvtDeviceD0EntryPostInterruptsEnabled callback and calling this from there help?

Thanks
Sudheer

All of the initial calls to the init and power up related callbacks are before or during processing of the start request. None of them are after. The tried and true way is to register for HID notifications and when notified, open it up, check the PDO and if it is your stack’s PDO you have opened your device, otherwise close it. I have heard of using other callbacks which happen to be invoked after processing the pnp start like EvtDeviceRelationsQuery for child relations and using that implementation detail to open the target.

d

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

Hi Doron,

No, with the remote target the open is what fails with “STATUS_NO_DEVICE”. I do not get to the point of trying to send the IOCTL.
ntStatus = WdfIoTargetOpen(wdfIoTarget, &wdfIoTargetOpenParams);

I tried this from D0Exit which also had the same problem.

Would there be a better place to call this from (other than making an external IOCTL call to trigger this) ? I do not have any interrupts etc but would providing a EvtDeviceD0EntryPostInterruptsEnabled callback and calling this from there help?

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

Hi Doron,

Thanks for your inputs, appreciate it!

  1. Regarding HID notifications, is there a DEVICE INTERFACE GUID that I can register for ?
    From the link: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731(v=vs.85).aspx
    If the driver is not a function or filter driver, it typically uses Plug and Play notification to find a collection

  2. I did see AddDevice getting called twice; is this expected?

  3. I tried to supply a EvtDeviceIoControl for handling ioctl’s from user space and call the collection/GET_FEATURE ioctl’s to the remote target(using pdoname).
    I was able to do the target open but these ioctl’s came to my EvtDeviceIoControl. From here how can I forward without getting the PRIVILIGE error? If I use the local IO target I do get the privilige error.

Thanks
Sudheer

  1. there is HID device interface guid. I just remembers a simpler solution. You register your own device interface guid and then listen for its arrival and then open yourself up, making sure the create irp goes all the way down the stack.

  2. if you are installed on one device, not expected. If you installed your driver with devcon install, which creates a root device, it could explain it. You could also be failing start, the stack is torn down and then built up again.

  3. how are you formatting the request to send down the stack on the local io target? Are you using WdfRequestFormatRequestUsingCurrentType? If that is not working, in addition to the call afterwards you should set the file object manually

PIRP irp = WdfRequestWdmGetIrp(request);
IoGetNextIrpStackLocation(irp)->FileObject = IoGetCurrentIrpStackLocation(irp)

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.co.in
Sent: Sunday, July 17, 2016 5:49 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

Hi Doron,

Thanks for your inputs, appreciate it!

1. Regarding HID notifications, is there a DEVICE INTERFACE GUID that I can register for ?
From the link: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731(v=vs.85).aspx
If the driver is not a function or filter driver, it typically uses Plug and Play notification to find a collection

2. I did see AddDevice getting called twice; is this expected?

3. I tried to supply a EvtDeviceIoControl for handling ioctl’s from user space and call the collection/GET_FEATURE ioctl’s to the remote target(using pdoname).
I was able to do the target open but these ioctl’s came to my EvtDeviceIoControl. From here how can I forward without getting the PRIVILIGE error? If I use the local IO target I do get the privilige error.

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

  1. Will look into this.

  2. I am using “devcon update” and not install to avoid the “root” related side effect. Will see if there is a failure somewhere that I might be missing.

  3. This is what I am doing for forwarding:
    WDF_REQUEST_SEND_OPTIONS wdfRequestSendOptions;

WdfRequestFormatRequestUsingCurrentType(p_wdfRequest);
WDF_REQUEST_SEND_OPTIONS_INIT(&wdfRequestSendOptions, WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);

bStatus = WdfRequestSend(p_wdfRequest, wdfIoTarget, &wdfRequestSendOptions);

Will try to manually set the FileObject.

Thanks!

It seems WdfRequestFormatRequestUsingCurrentType(p_wdfRequest) does copy the fileobject. I assume you were meaning to do the following?

IoGetNextIrpStackLocation(irp)->FileObject = IoGetCurrentIrpStackLocation(irp)->FileObject

The GET_FEATURE still had the same error. The WdfRequestSend call seems to call the DeviceIoControl again - is this expected? It does seem to send it after that.

Also after sometime it crashed if I do the copy manually (after I get the FAILURE). Otherwise it just seems to fail the IOCTL.

00 xxx_hid!EvtIoDeviceControl <-----------------------Again EvtDeviceIoControl?
01 Wdf01000!FxIoQueueIoDeviceControl::Invoke
02 Wdf01000!FxIoQueue::DispatchRequestToDriver
03 Wdf01000!FxIoQueue::DispatchEvents
04 Wdf01000!FxIoQueue::QueueRequest
05 Wdf01000!FxPkgIo::DispatchStep2
06 Wdf01000!FxPkgIo::DispatchStep1
07 Wdf01000!DispatchWorker
08 Wdf01000!FxDevice::Dispatch
09 Wdf01000!FxDevice::DispatchWithLock
0a Wdf01000!imp_WdfRequestSend
0b xxx_hid!WdfRequestSend
0c xxx_hid!EvtIoDeviceControl <-----------------------EvtDeviceIoControl
0d Wdf01000!FxIoQueueIoDeviceControl::Invoke
0e Wdf01000!FxIoQueue::DispatchRequestToDriver
0f Wdf01000!FxIoQueue::DispatchEvents
10 Wdf01000!FxIoQueue::QueueRequest
11 Wdf01000!FxPkgIo::DispatchStep2
12 Wdf01000!FxPkgIo::DispatchStep1
13 Wdf01000!DispatchWorker
14 Wdf01000!FxDevice::Dispatch
15 Wdf01000!FxDevice::DispatchWithLock
16 Wdf01000!FxIoTarget::SubmitSync
17 Wdf01000!FxIoTargetSendIoctl
18 Wdf01000!imp_WdfIoTargetSendIoctlSynchronously
19 xxx_hid!WdfIoTargetSendIoctlSynchronously
1a xxx_hid!xxxHidGetCollection <--------------------- Call GET_FEATURE
1b xxx_hid!EvtIoDeviceControl
1c Wdf01000!FxIoQueueIoDeviceControl::Invoke
1d Wdf01000!FxIoQueue::DispatchRequestToDriver
1e Wdf01000!FxIoQueue::DispatchEvents
1f Wdf01000!FxIoQueue::QueueRequest

I just tried to put some bp in HIDClass…
xxx_hid!EvtIoDeviceControl+0x136:
fffff801d4e21f36 cc int 3 2: kd\> g Breakpoint 1 hit HIDCLASS!HidpIrpMajorDeviceControl+0x687: fffff801d4b82ef7 8bf0 mov esi,eax
2: kd> g
Breakpoint 0 hit
HIDCLASS!HidpMajorHandler+0x159:
fffff801d4b82629 eb0b jmp HIDCLASS!HidpMajorHandler+0x166 (fffff801d4b82636)
2: kd> g
XXXHidGetCollection: IOCTL_HID_GET_FEATURE failed 0xc0000061

Did you forward the create request down the stack in EvtDeviceFileCreate for hidclass to process it? If not, you must.

Get Outlook for Androidhttps:

On Sun, Jul 17, 2016 at 9:46 PM -0700, “xxxxx@yahoo.co.in” > wrote:

It seems WdfRequestFormatRequestUsingCurrentType(p_wdfRequest) does copy the fileobject. I assume you were meaning to do the following?

IoGetNextIrpStackLocation(irp)->FileObject = IoGetCurrentIrpStackLocation(irp)->FileObject

The GET_FEATURE still had the same error. The WdfRequestSend call seems to call the DeviceIoControl again - is this expected? It does seem to send it after that.

Also after sometime it crashed if I do the copy manually (after I get the FAILURE). Otherwise it just seems to fail the IOCTL.

00 xxx_hid!EvtIoDeviceControl <-----------------------Again EvtDeviceIoControl?
01 Wdf01000!FxIoQueueIoDeviceControl::Invoke
02 Wdf01000!FxIoQueue::DispatchRequestToDriver
03 Wdf01000!FxIoQueue::DispatchEvents
04 Wdf01000!FxIoQueue::QueueRequest
05 Wdf01000!FxPkgIo::DispatchStep2
06 Wdf01000!FxPkgIo::DispatchStep1
07 Wdf01000!DispatchWorker
08 Wdf01000!FxDevice::Dispatch
09 Wdf01000!FxDevice::DispatchWithLock
0a Wdf01000!imp_WdfRequestSend
0b xxx_hid!WdfRequestSend
0c xxx_hid!EvtIoDeviceControl <-----------------------EvtDeviceIoControl
0d Wdf01000!FxIoQueueIoDeviceControl::Invoke
0e Wdf01000!FxIoQueue::DispatchRequestToDriver
0f Wdf01000!FxIoQueue::DispatchEvents
10 Wdf01000!FxIoQueue::QueueRequest
11 Wdf01000!FxPkgIo::DispatchStep2
12 Wdf01000!FxPkgIo::DispatchStep1
13 Wdf01000!DispatchWorker
14 Wdf01000!FxDevice::Dispatch
15 Wdf01000!FxDevice::DispatchWithLock
16 Wdf01000!FxIoTarget::SubmitSync
17 Wdf01000!FxIoTargetSendIoctl
18 Wdf01000!imp_WdfIoTargetSendIoctlSynchronously
19 xxx_hid!WdfIoTargetSendIoctlSynchronously
1a xxx_hid!xxxHidGetCollection <--------------------- Call GET_FEATURE
1b xxx_hid!EvtIoDeviceControl
1c Wdf01000!FxIoQueueIoDeviceControl::Invoke
1d Wdf01000!FxIoQueue::DispatchRequestToDriver
1e Wdf01000!FxIoQueue::DispatchEvents
1f Wdf01000!FxIoQueue::QueueRequest

I just tried to put some bp in HIDClass…
xxx_hid!EvtIoDeviceControl+0x136:
fffff801d4e21f36 cc int 3<br>2: kd&gt; g<br>Breakpoint 1 hit<br>HIDCLASS!HidpIrpMajorDeviceControl+0x687:<br>fffff801d4b82ef7 8bf0 mov esi,eax
2: kd> g
Breakpoint 0 hit
HIDCLASS!HidpMajorHandler+0x159:
fffff801d4b82629 eb0b jmp HIDCLASS!HidpMajorHandler+0x166 (fffff801d4b82636)
2: kd> g
XXXHidGetCollection: IOCTL_HID_GET_FEATURE failed 0xc0000061


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

I have not set a callback for evtdevicefilecreate; was not aware that was needed?

Are you calling WdfFdoInitSetFilter?

Get Outlook for Androidhttps:

On Mon, Jul 18, 2016 at 12:41 AM -0700, “xxxxx@yahoo.co.in” > wrote:

I have not set a callback for evtdevicefilecreate; was not aware that was needed?


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

I was calling InitSetFilter at some point but I was getting an error in the target open (I believe for SHARE ACCESS being incompatible).
So I had commented that out. In that case it would have sent the create down without the callback being needed. I was not sure if calling
SetFilter without having it in the INF had any side effects?

Meanwhile providing the EvtDeviceFileCreate callback and passing it down worked! Even the SetFilter without providing the File callbacks work now!
I am at least able to do a GET_FEATURE and see some data.
Thanks for being patient and providing your responses!

Had a related followup, if you don’t mind:

  1. If I do not want to load this as a function driver and want to talk to the HIDClass directly would that be doable? Is there a good documentation on MSDN for that?
    The only thing I found (https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731(v=vs.85).aspx) does not have much data for KMDF, especially the HID interface
    I should be registering for etc.

  2. Since our collection gets exposed as a UP=20(Sensor); and if we don’t load our driver on that device then I assume the inbox MS Sensor driver would claim it. In that
    case would there be an issue in doing 1. above?

  3. The reason I am asking about the above is that we need to exchange data with the ACPI stack. We will have a ACPI driver that loads on an ACPI device and that can talk
    to this HID driver via driver-driver interface (QueryInterface). If 1. is doable then probably the ACPI driver could find the collection and start sending GET/SET feature directly?

Thanks
Sudheer

  1. yes you can open a HID for from outside the stack. IoRegisterPlugPlayNotification on the HID device interface guid (GUID_DEVINTERFACE_HID). You would then open each notification and see if it is your HID. You would then have to register for file handle notifications so you can close the handle in case the HID is removed. The opening and handle notifications are handled by a remote io target.

  2. if the inbox hid sensor driver opens the HID for exclusive access (I don’t know either way), then no, you couldn’t open it. You can let the in box driver load and then try the experiment from a user mode app, the sensor driver won’t know the difference.

  3. yes, also assuming the in box sensor driver lets you still open the HID

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

I was calling InitSetFilter at some point but I was getting an error in the target open (I believe for SHARE ACCESS being incompatible).
So I had commented that out. In that case it would have sent the create down without the callback being needed. I was not sure if calling SetFilter without having it in the INF had any side effects?

Meanwhile providing the EvtDeviceFileCreate callback and passing it down worked! Even the SetFilter without providing the File callbacks work now!
I am at least able to do a GET_FEATURE and see some data.
Thanks for being patient and providing your responses!

Had a related followup, if you don’t mind:

1. If I do not want to load this as a function driver and want to talk to the HIDClass directly would that be doable? Is there a good documentation on MSDN for that?
The only thing I found (https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731(v=vs.85).aspx) does not have much data for KMDF, especially the HID interface I should be registering for etc.

2. Since our collection gets exposed as a UP=20(Sensor); and if we don’t load our driver on that device then I assume the inbox MS Sensor driver would claim it. In that case would there be an issue in doing 1. above?

3. The reason I am asking about the above is that we need to exchange data with the ACPI stack. We will have a ACPI driver that loads on an ACPI device and that can talk to this HID driver via driver-driver interface (QueryInterface). If 1. is doable then probably the ACPI driver could find the collection and start sending GET/SET feature directly?

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

Thanks Doron!

Hi Doron,

Tried getting the HID class interface:

I was able to call GET_COLLECTION_INFO for most of the HID collection that came along and check the VID/PID but for my device (on which the MS HID Sensor driver is loaded and there is only one)
the TargetOpen failed with STATUS_INVALID_DEVICE_REQUEST.

Snippet from logdump (last one is the failure):

120: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE15206438, Waiting on Dispose event FFFFD000727D7450
121: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 derefing PDO FFFFE001EADFA060 on close
122: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 derefing FileObj FFFFE001EADFC430 on close
123: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 closing handle FFFFFFFF800004B0 on close
124: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE15410228 returned status STATUS_SUCCESS, info 0x0
125: FxIoTargetRemote::ClearTargetPointers - WDFIOTARGET 00001FFE15410228 cleared pointers FFFFD000727CF4E0 state WdfIoTargetDeleted, open state 3, pdo FFFFE001EADF9060, fileobj FFFFE001EABEFCD0, handle FFFFFFFF80000434
126: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE15410228, Waiting on Dispose event FFFFD000727CF450
127: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 derefing PDO FFFFE001EADF9060 on close
128: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 derefing FileObj FFFFE001EABEFCD0 on close
129: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 closing handle FFFFFFFF80000434 on close
130: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE154105C8 returned status STATUS_SUCCESS, info 0x0
131: FxIoTargetRemote::ClearTargetPointers - WDFIOTARGET 00001FFE154105C8 cleared pointers FFFFD000727CF4E0 state WdfIoTargetDeleted, open state 3, pdo FFFFE001EADC7060, fileobj FFFFE001EADFC430, handle FFFFFFFF80000434
132: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE154105C8, Waiting on Dispose event FFFFD000727CF450
133: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 derefing PDO FFFFE001EADC7060 on close
134: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 derefing FileObj FFFFE001EADFC430 on close
135: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 closing handle FFFFFFFF80000434 on close
136: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE14018368 returned status 0xc0000010(STATUS_INVALID_DEVICE_REQUEST), info 0x3c006a

Would that be an indication that the HID Sensor driver is not allowing the open like you had mentioned previously?
Is there a way to interpret the info code?

Thanks!

That would be my guess. Even if it allowed opens, the sensor driver would talk “sensors io”, not “hid io”. If you need the hid sensor to be consumed as a sensor by the OS AND still query it for raw data, you need to either filter below the hid sensor driver or figure out how to open a handle to the sensor driver and see if there is raw or cooked sensor data that meets your needs. Getting the create handle to succeed might be as simple as configuring the umdf hid sensor driver to allow km creates ( by default umdf drivers do not allow km originated creates)

Get Outlook for Androidhttps:

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

Hi Doron,

Tried getting the HID class interface:

I was able to call GET_COLLECTION_INFO for most of the HID collection that came along and check the VID/PID but for my device (on which the MS HID Sensor driver is loaded and there is only one)
the TargetOpen failed with STATUS_INVALID_DEVICE_REQUEST.

Snippet from logdump (last one is the failure):

120: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE15206438, Waiting on Dispose event FFFFD000727D7450
121: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 derefing PDO FFFFE001EADFA060 on close
122: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 derefing FileObj FFFFE001EADFC430 on close
123: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 closing handle FFFFFFFF800004B0 on close
124: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE15410228 returned status STATUS_SUCCESS, info 0x0
125: FxIoTargetRemote::ClearTargetPointers - WDFIOTARGET 00001FFE15410228 cleared pointers FFFFD000727CF4E0 state WdfIoTargetDeleted, open state 3, pdo FFFFE001EADF9060, fileobj FFFFE001EABEFCD0, handle FFFFFFFF80000434
126: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE15410228, Waiting on Dispose event FFFFD000727CF450
127: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 derefing PDO FFFFE001EADF9060 on close
128: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 derefing FileObj FFFFE001EABEFCD0 on close
129: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 closing handle FFFFFFFF80000434 on close
130: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE154105C8 returned status STATUS_SUCCESS, info 0x0
131: FxIoTargetRemote::ClearTargetPointers - WDFIOTARGET 00001FFE154105C8 cleared pointers FFFFD000727CF4E0 state WdfIoTargetDeleted, open state 3, pdo FFFFE001EADC7060, fileobj FFFFE001EADFC430, handle FFFFFFFF80000434
132: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE154105C8, Waiting on Dispose event FFFFD000727CF450
133: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 derefing PDO FFFFE001EADC7060 on close
134: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 derefing FileObj FFFFE001EADFC430 on close
135: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 closing handle FFFFFFFF80000434 on close
136: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE14018368 returned status 0xc0000010(STATUS_INVALID_DEVICE_REQUEST), info 0x3c006a

Would that be an indication that the HID Sensor driver is not allowing the open like you had mentioned previously?
Is there a way to interpret the info code?

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

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

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

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?

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

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

@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?