After a few hours of digging, I finally found the source of a bug in a PNP
bus driver, so I thought I would share the pain. Or at least the relief
from pain.
Basically, the bug boiled down to the bus FDO’s handler for
IRP_MN_QUERY_DEVICE_RELATIONS/BusRelations. The driver was returning
IoStatus.Status = STATUS_SUCCESS, and IoStatus.Information = 0/NULL, when
the list of devices to return was empty.
PNP will silently accept this, without any grumpy debug spew, Driver
Verifier warnings, etc. But it will silently cause problems in some
situations. Specifically, when removing child devices. Basically, the PNP
manager does NOT consider a NULL device relations list to be equivalent to a
non-NULL list with Count = 0. The PNP manager will NOT reconcile the new
“empty” list with the old non-empty list, and will therefore not consider
missing child devices to be removed.
PNP team: It might help to have a KdPrint warning when a bus FDO has
previously enumerated more than zero devices, and a future request completes
with IoStatus.Information = 0. Or a Driver Verifier warning, etc.
This is probably old news for a lot of people on this list, but this might
save someone else a headache.
– arlie
I feel your pain, and I have certainly done things like this and wasted
plenty of hours. I also do not disagree with putting warnings like this in
code or tools, although MSFT rarely does so. But, this is clearly
documented in the DDK docs on IRP_MN_QUERY_DEVICE_RELATIONS:
“If there is no child device present on the bus, the driver sets the count
to zero in the DEVICE_RELATIONS structure and returns success.”
Bill M.
“Arlie Davis” wrote in message
news:xxxxx@ntdev…
> After a few hours of digging, I finally found the source of a bug in a PNP
> bus driver, so I thought I would share the pain. Or at least the relief
> from pain.
>
> Basically, the bug boiled down to the bus FDO’s handler for
> IRP_MN_QUERY_DEVICE_RELATIONS/BusRelations. The driver was returning
> IoStatus.Status = STATUS_SUCCESS, and IoStatus.Information = 0/NULL, when
> the list of devices to return was empty.
>
> PNP will silently accept this, without any grumpy debug spew, Driver
> Verifier warnings, etc. But it will silently cause problems in some
> situations. Specifically, when removing child devices. Basically, the
> PNP
> manager does NOT consider a NULL device relations list to be equivalent to
> a
> non-NULL list with Count = 0. The PNP manager will NOT reconcile the new
> “empty” list with the old non-empty list, and will therefore not consider
> missing child devices to be removed.
>
> PNP team: It might help to have a KdPrint warning when a bus FDO has
> previously enumerated more than zero devices, and a future request
> completes
> with IoStatus.Information = 0. Or a Driver Verifier warning, etc.
>
> This is probably old news for a lot of people on this list, but this might
> save someone else a headache.
>
> – arlie
>
>
>
>
Yeah, I found that text, after I found the real bug in the driver, in order
to see if we had just missed something obvious. Cold comfort.
At least in C, treating a NULL pointer to an array and an array with zero
elements in it as equivalent is fairly common. I’m not arguing that that
WDM is wrong here, just that the totally silent failure was really difficult
to diagnose.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Friday, January 06, 2006 4:17 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Wasted time and a discovery
I feel your pain, and I have certainly done things like this and wasted
plenty of hours. I also do not disagree with putting warnings like this in
code or tools, although MSFT rarely does so. But, this is clearly
documented in the DDK docs on IRP_MN_QUERY_DEVICE_RELATIONS:
“If there is no child device present on the bus, the driver sets the count
to zero in the DEVICE_RELATIONS structure and returns success.”
Bill M.