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

Ok,
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.

Thanks for your time,
Justin

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