Re: XP io manger cancels my queued Irp's, but not 2k

Hi,
Thanks for your replies. When I say IO manager is not canceling Irps,
I think what I really mean is the Hidclass driver was not canceling them
(which results in the io manager calling the cancel routines). The driver
is registered not polled, and no Irps actually reach the USB bus when they
need to be cancelable, because the hid mini driver can disappear without
the usb device disappearing (the mini driver is a child device of my usb
function driver). As soon as I report to the PNP manager that my hid mini
driver is unloading, on xp the hidclass driver cancels the 2 outstanding
Irps which in turn lets the driver unload. On 2k, this doesn’t happen.

On a side note, I have not yet figured out how to cancel an outstanding USB
request due to a timeout or device failure etc… I tried building an
usb irp/urb etc, sending it, canceling it with iocancelirp() to no avail.

-Justin

At 01:43 AM 10/3/2002, you wrote:

Justin Frodsham wrote:
> I have read 3 books (Oney’s, Cant’s, Viscarola’s and all the DDK docs)
> not to mention the articles from the OSR website. I still cannot
> understand the 2k issue. Under XP, the IO manager (or the hid driver)
> calls the cancel routines for my queued irps BEFORE sending the surprise
> removal IRP. These IRP’s orginated from the Hidclass driver, I did not
> create them. They will last indefinatly (like a keyboard) if there is no
> input to be had. Futher, one Irp is always forwarded on to the next lower
> driver and queued there. My queue cleanup routine takes care of the Irps
> left in the local queue, however the Irp sent to the lower driver still
> has to be cancelled. XP calls the cancel routine set up in the lower
> driver for this Irp. 2k does not. I do not think I am allowed to call
> IoCancelIrp(), because I did not create it. What am I missing here? I
> could really use some input. As soon as I solve this issue I think I can
> submit my driver to WHQL.

Ah. You should have mentioned this was a HID minidriver in your first
post. Some more facts would be helpful in diagnosing your problem. What
sort of driver is underneath you? When you registered with HIDCLASS, did
you specify the polling flag, or not?

As a point of design comparison, Microsoft’s HIDUSB doesn’t do anything
special to handle the surprise removal case because it specifies “not
polled” and simply forwards every read-report IRP down to the USB bus
driver after changing the control code and adding a URB pointer.
HIDCLASS keeps two read-report requests active at all times, and it
cancels them at all the right times for PnP and power operations.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com


You are currently subscribed to ntdev as: zeppelin@io.com
To unsubscribe send a blank email to %%email.unsub%%