> When my bus driver got first created, all the child are enumerated. When
I’m deleting one of the child and that I’m doing a scan for hardware change
after in the device manager, Windows did’nt restart the deleted child. The
functional device of my bus driver is always sending the same PDO list to
the plug and play manager (in response of a IRP_MN_QUERY_DEVICE_RELATIONS).
A cite from the documentation:
"If the bus driver reported this device in its most recent response to an IRP_MN_QUERY_DEVICE_RELATIONS request for BusRelations,
the device is still physically present on the machine. In this case, the bus driver:
a… Retains the PDO for the device until the device has been physically removed.
b… Sets Irp->IoStatus.Status to STATUS_SUCCESS.
c… Completes the IRP with IoCompleteRequest.
d… Returns from the DispatchPnP routine "
End of cite.
You must not call IoDeleteDevice in your REMOVE path if the PDO was reported to PnP in device relations. Such a “REMOVE with a PDO
still in relations” is sent by “disable” or “update driver” from Device Manager, and they must not kill a PDO, they must retain the
PDO (and thus devnode) to be displayed as “disabled” in Device Manager tree and then re-activated by START. Only the real device
disappear (no longer on the bus) must kill the PDO.
The correct way to handle removes is:
- maintain the “killed” and “reported in relations” flags in the PDO.
- in device disappear path (real disappear of yours, not the REMOVE path, your bus driver’s path which is called if the child does
no longer exist) - mark the device as “killed” and call IoInvalidateDeviceRelations. Killed PDOs are not reported in relations.
- in MN_QUERY_RELATIONS path:
- mark all PDOs as not “reported in relations”
- then assemble a PDO pointer array, and do not include “killed” PDOs there.
- then mark all PDOs in a pointer array as “reported in relations”.
- complete
- in MN_REMOVE_DEVICE path (a part of, see the documentation for more details):
- if the device is “reported in relations”
// This is a REMOVE request initiated by the Device Manager “disable” or “update
// driver” features
- complete
- else
// This REMOVE request is due to device really disappeared from the relations
- delete the PDO
- complete
Note that you must not have this in surprise removal case (SURPRISE_REMOVAL before REMOVE. SURPRISE_REMOVAL is sent by PnP if the
device disappeared from the relations without the user-initiated action in the Device Manager - “disable” or “update driver”). Just
delete the PDO in this case.
Also note that failed START causes REMOVE. In this case, the PDO must not be deleted too, this is automatically handled by the “do
not delete PDOs reported in relations” rule.
For instance - I have buggy Adaptec/Roxio drivers from EasyCD Creator. They are both upper and lower filters to the CD/DVD-ROM
devnodes.
The bug is that after awakening from hibernate, they usually fail START due to some strange reasons. In this case, the CD/DVD-ROM
devnode is dead. Even the “Advanced Properties” (DVD) tab is not displayed, the CD also has no drive letter. There is also no device
interface symlinks to it.
Nevertheless, the devnode (created by atapi.sys) is still there, regardless of START failure. It is not deleted on REMOVE followed
the failed START, and the REMOVE really was there since it deleted the symlinks.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com