STATUS_PRIVILEGE_NOT_HELD on a Read in a HID filter driver.

NTDEV
1

Hi,

I wrote a HID filter driver that sits below mousehid. The attempt is to park the IoReads coming from mousehid and generate new multiple IoReads to be sent down the default iotarget.

For the new requests, the sequence is WdfRequestCreate, WdfMemoryCreate, WdfIoTargetFormatRequestFromRead, WdfRequestSend. Pretty much like in the serial.c sample of the WDK. The only difference, which I hope doesn’t really matter, is that the new requests have a context of a few bytes with some info that I reuse later on.

Now, if I forward the IoRead coming from mousehid everything works fine. If I try to feed the iotarget with my ioreads, the completion routine gets called synchronously with WdfRequestSend returning status c0000061 (which is STATUS_PRIVILEGE_NOT_HELD).

I hardly believe the problem is actually a privilege one unless there is something in the requests of mousehid that the lower iotarget uses as a sort of token.

Does this ring a bell to anyone?

Thanks a lot in advance,
Marco.

2

Hidclass requires the PFILE_OBJECT that opened the stack for read access in the irp. This is why fwd’ing mouhid’s reads work, they contain the PFILE_OBJECT that mouhid opened. There are two ways you can fix this

  1. pull the PFILE_OBJECT out of the read request you receive and then manually add it to the request after you format it for read (IoGetNextIrpStackLocation(WdfRequestWdmGetIrp(request))->FileObject =<…>;)
  2. register an EvtDeviceFileCreate callback, if the request is asking for read access, send the request down synchronously using the default target and when it comes back successfully, create a new remote IO target, and use WDF_IO_TARGET_OPEN_PARAMS_INIT_EXISTING_DEVICE for the open params, passing WdfDeviceWdmGetAttachedDevice for the existing device, then assign openParams.TargetFileObject to the open request’s PFILE_OBJECT and then open the target. Then use this new io target when you format and send your own reads.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, October 28, 2010 11:55 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] STATUS_PRIVILEGE_NOT_HELD on a Read in a HID filter driver.

Hi,

I wrote a HID filter driver that sits below mousehid. The attempt is to park the IoReads coming from mousehid and generate new multiple IoReads to be sent down the default iotarget.

For the new requests, the sequence is WdfRequestCreate, WdfMemoryCreate, WdfIoTargetFormatRequestFromRead, WdfRequestSend. Pretty much like in the serial.c sample of the WDK. The only difference, which I hope doesn’t really matter, is that the new requests have a context of a few bytes with some info that I reuse later on.

Now, if I forward the IoRead coming from mousehid everything works fine. If I try to feed the iotarget with my ioreads, the completion routine gets called synchronously with WdfRequestSend returning status c0000061 (which is STATUS_PRIVILEGE_NOT_HELD).

I hardly believe the problem is actually a privilege one unless there is something in the requests of mousehid that the lower iotarget uses as a sort of token.

Does this ring a bell to anyone?

Thanks a lot in advance,
Marco.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Ohhh, I see. Seems easy to fix then.

Thank you so much. I really really appreciate it.

Marco.