Illegal behavior in USBCCGP.SYS ??

NTDEV
1

Hi,
While trying to trigger a surprise removal on a device by setting the
PNP_DEVICE_REMOVED bit in the IoStatus.Information of a
IRP_MN_QUERY_PNP_DEVICE_STATE request I noticed that this method does not
work on child devices of USB composite devices. A short debugging session
led me to the conclusion that when USBCCGP.SYS (the parent composite device
driver) handles this IRP for the PDO, it sets the IoStatus.Information to 0
(and by doing that, turns off all the bits that were set by other drivers in
the device stack). The DDK documentation clearly states: “If another driver
has set a PNP_DEVICE_STATE in Irp->IoStatus.Information, a driver must take
care to modify the flags in that bitmask rather than overwrite the whole
structure.”. How is it legal then for USBCCGP.SYS to turn off all the flags
when handling the IRP for the PDO ? How can I trigger a surprise remove if I
cannot count on the driver in the device stack to act legaly ? I thought of
the possibility of setting a completion routine and setting the bit after
USBCCGP.SYS completes the IRP, but the DDK also states: “This IRP is handled
first by the driver at the top of the device stack and then by each next
lower driver in the stack”, so I can’t do that also… Can anyone explain
USBCGP’s behavior ? Is it by design ?

Thanks,
Shahar.

2

Set the bits you want set in the completion routine for the PIRP. It is
OK to add flags on the way back up the stack in this case.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Wednesday, October 06, 2004 5:26 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Illegal behavior in USBCCGP.SYS ??

Hi,
While trying to trigger a surprise removal on a device by setting the
PNP_DEVICE_REMOVED bit in the IoStatus.Information of a
IRP_MN_QUERY_PNP_DEVICE_STATE request I noticed that this method does
not
work on child devices of USB composite devices. A short debugging
session
led me to the conclusion that when USBCCGP.SYS (the parent composite
device
driver) handles this IRP for the PDO, it sets the IoStatus.Information
to 0
(and by doing that, turns off all the bits that were set by other
drivers in
the device stack). The DDK documentation clearly states: “If another
driver
has set a PNP_DEVICE_STATE in Irp->IoStatus.Information, a driver must
take
care to modify the flags in that bitmask rather than overwrite the whole
structure.”. How is it legal then for USBCCGP.SYS to turn off all the
flags
when handling the IRP for the PDO ? How can I trigger a surprise remove
if I
cannot count on the driver in the device stack to act legaly ? I thought
of
the possibility of setting a completion routine and setting the bit
after
USBCCGP.SYS completes the IRP, but the DDK also states: “This IRP is
handled
first by the driver at the top of the device stack and then by each next
lower driver in the stack”, so I can’t do that also… Can anyone
explain
USBCGP’s behavior ? Is it by design ?

Thanks,
Shahar.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com