Anyone who has written, or worked with, a WDM driver is most likely well
aware of the PnP Manager’s STD. No, I am not referring to a transmitted
disease, although like others I have talked to I am beginning to second
guess the definition. Actually, I am refering to the State Transition
Diagram which documents the states a driver needs to support and the IRP
events which cause the transitions between the states to occur.
While the DDK documents this diagram and the transition IRP events quite
well, what I find the documentation to be sorely lacking is a good
description on what triggers the PnP Manager to issue these state
transitioning IRP’s. It also does nto document what is the entire series of
IRP’s issued to add, start, and remove a device from the system.
Consider a toaster bus which allows a plugin control to enumerate several
toaster children at the same time. The bus invalidates it’s relations and
responds to an IRP_MN_QUERY_DEVICE_RELATIONS for BusRelations with a table
of PDO’s for all the children being enumerated via the plugin. The PnP
Manager now cycles through a series of IRP’s which results in the first
toaster child being added to the system and started. Now, one would expect
that the Manager would begin a series of IRP’s to add and start the next
toaster child. However, it instead issues a IRP_MN_QUERY_DEVICE_RELATIONS
for RemoveRelations to the first toaster child. All versions of the Toaster
sample I have seen, even in the latest 3678 beta release of the DDK, do not
respond to this IRP. Consequently the FDO for toaster child 1 passes this
IRP on down the stack and the PDO for the child responds to the IRP with the
default STATUS_NOT_SUPPORTED status passed in since it is not a
TargetDeviceRelation request. The IRP is then followed by the PnP Manager
issuing an IRP_MN_QUERY_REMOVE_DEVICE to the first toaster which causes the
FDO for the first toaster child to transition to the PENDINGREMOVE state and
it’s PDO to complete the IRP with STATUS_SUCCESS, since it has not
processing to perform.
The end result is that the PnP Manager, and conversely the associated Add
New Hardware wizard, performs a branch and hang and the remaining toaster
children are orphaned (i.e. never to be added to the system).
I would appreciate it greatly if anyone could explain why the PnP Manager
issues the IRP_MN_QUERY_DEVICE_RELATIONS for RemoveRelations after the
first child is started and why the remaining children are never added to the
system. I would also be curious to know why the PnP Manager does a branch
and hang when the proper state transition occurs within the driver and the
affirmative response is issued for the IRP_MN_QUERY_REMOVE_DEVICE.