[kmdf] No activity after starting continuous reader.

NTDEV
1

Hi all,

I wrote a filter driver intended to filter/extend functionality for some HID devices. Since these devices require the driver to send device vendor requests, I decided, to have access to the USB iotarget to write a lower filter driver for hidusb and look for IOCTL_INTERNAL_USB_SUBMIT_URB function URB_FUNCTION_BULK_OR_TRANSFER.

For several reasons I needed to decouple the requests coming from hidusb and the one sent down so I used a cont reader to read from the device and serve the URBs coming form the top.

The driver works just fine with several devices with one USB interface.

Unfortunately I’m having weird problems with one that has 2 USB interfaces. Ideally the driver would need to run on only one of them so, as a first attempt I tried loading it on the interface instance. As soon as the cont reader starts, the device stops sending reports.

I’m going to snoop the USB traffic to understand the problem better but I wonder if there’s anything that wrong that I’m doing in my setup.

Another thing: on the same device (which is a special mouse), I tried to avoid the cont reader and install a completion routine on the IOCTL_INTERNAL_USB_SUBMIT_URB/URB_FUNCTION_BULK_OR_TRANSFER request. At completion, I use WdfRequestRetrieveOutputBuffer to retrieve the buffer. Some initial requests complete with a NULL buffer (however WdfRequestRetrieveOutputBuffer doesn’t fail which I find weird), whereas upon movement (of the mouse) I get a buffer with a gigantic size (a number that doesn’t really make any sense and looks more like a pointer than anything else). On those completions, if I look at the Information field of CompletionParams->IoStatus, the returned size is 0. In those cases, if I just complete the requrest without doing anything, I see the cursor moving on the screen which means that data is somewhere but I just don’t see it.

Does anybody have insights on this?

Thanks in advance,
Marco.

2

I can’t think of a specific reason why this wouldn’t work, but by inserting a continuous reader between the original function driver and device, you may be slightly altering their interactions. A few things I thought of they may or may not apply.

  1. If the continuous reader receives data, and there is no pending URB from the HID function driver, do you cache it somewhere?

  2. The continuous reader also handles some error conditions. This can be done automatically by KMDF on your behalf (clear state, send new reads to device) or you can setup your own handler for custom actions. It seems you would want to do the latter and pass it back to the HID function driver.

I’m curious why a pass-thru filter that would inspect modify the URB’s as they pass through didn’t work for your scenario.

With the Request Buffer questions, these are mostly a thin wrapper around the IRP with some abstractions for different IO methods. There is nothing WDF specific about the data you are seeing, someone who is more familiar with input would have to comment on how to get to the data you want. If you are interested in 0 length buffers failing, take a look at the “MinimumRequiredSize” to WdfRequestRetrieveOutputBuffer.

Brandon

3

Hi Brandon,

thank you for your reply.

Well, I came to the cont. reader mostly because I found problems (different problems) in everything else I tried. One of the requirements I have is to be able to “drop” reports coming from the device.
My original attempt was to use the URBs generated by hidusb, set a completion routine and, in the completion routine, forward the request back to the default iotarget (after reformatting it and all).
This caused a bugcheck and I could not point out the reason for it really.
Then I decided to go for the cont reader approach. It’s somewhat simpler and I provided a queue as buffering to compensate for the lack of synchronization between the URBs from hidusb and the completions of the cont. reader.
The driver works pretty fine with all the devices I tried except one that has the peculiarity of having multiple interfaces whereas I need to attach just one.

Anyway right now I’m back to the original design of just filtering URBs. I somewhat parked the idea of dropping reports (although I will have to deal with it at some point) for now.

The problem with WdfRequestRetrieveOutputBuffer has really to do with the minimumrequiredsize which is set to 1. Interestingly, the size value returned by WdfRequestRetrieveOutputBuffer is not zero but really very large number (I think it’s actually not meaningful). What is zero is the Information value in the IoStatus that is where I hoped to get the actual information of the coming report.

Right now I’m somewhat stamped since whatever I try seems to fail in a way that I don’t expect and I really don’t know where to check to find information about the problem.

Thanks,
Marco.

4

WdfRequestRetrieveInput/OutputBuffer knows how to decode stand IOCTLs, reads and writes. Internal IOCTLs can be decoded if the formatting in the io stack location conforms to normal IOCTL encoding. The internal submit URB IOCTL does not conform to the standard encoding, so the these APIs cannot return sane values. You need to get the URB yourself and get the length yourself. Same for IoStatus.Information in the submit URB case. It is never set (again, it does not follow the default encoding like std formats).

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, November 22, 2010 4:00 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] [kmdf] No activity after starting continuous reader.

Hi Brandon,

thank you for your reply.

Well, I came to the cont. reader mostly because I found problems (different problems) in everything else I tried. One of the requirements I have is to be able to “drop” reports coming from the device.
My original attempt was to use the URBs generated by hidusb, set a completion routine and, in the completion routine, forward the request back to the default iotarget (after reformatting it and all).
This caused a bugcheck and I could not point out the reason for it really.
Then I decided to go for the cont reader approach. It’s somewhat simpler and I provided a queue as buffering to compensate for the lack of synchronization between the URBs from hidusb and the completions of the cont. reader.
The driver works pretty fine with all the devices I tried except one that has the peculiarity of having multiple interfaces whereas I need to attach just one.

Anyway right now I’m back to the original design of just filtering URBs. I somewhat parked the idea of dropping reports (although I will have to deal with it at some point) for now.

The problem with WdfRequestRetrieveOutputBuffer has really to do with the minimumrequiredsize which is set to 1. Interestingly, the size value returned by WdfRequestRetrieveOutputBuffer is not zero but really very large number (I think it’s actually not meaningful). What is zero is the Information value in the IoStatus that is where I hoped to get the actual information of the coming report.

Right now I’m somewhat stamped since whatever I try seems to fail in a way that I don’t expect and I really don’t know where to check to find information about the problem.

Thanks,
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