I’m working on a Bus Driver in KMDF and encountering strange behavior during return (Resume) from Hibernate:
Initial Load: When the driver first loads, it dynamically reports the child devnodes, and the Framework/OS exposes them immediately (via the callback of EvtChildListCreateDevice to create PDOs).
D0Exit (Hibernate): During hibernation exit, the driver unplugs all devices (reports those devnodes as missing) by calling WdfChildListBeginScan() and WdfChildListEndScan() as shown in the sample.
D0Entry (Resume): Upon resuming, the driver again unplugs all devices. After this, it dynamically reports the child devnodes once more. However, this time, the callback EvtChildListCreateDevice to create the PDOs takes more than 10 seconds.
Questions:
What could be causing this delay in EvtChildListCreateDevice during resume?
How can I debug this issue? (I don’t see anything noteworthy in the Framework WPP Logs)
Any insights or suggestions would be greatly appreciated!
PNP and system power state changes (not device power state) share the same lock and serialized queue. IOW, a long running system power event will block pnp state changes (start, stop, remove, enumeration, etc) and v.v. Drivers used to hold onto the system power irp until the device power irp completed, this held onto the state lock for quite some time. All the fast resume work in XP and Vista was remove this behavior:request the device power irp and then immediately complete the system power irp so that other parts of the system could wake up.
why the history? the 10s you are seeing is quite possibly due to a driver holding on to a system power irp or pnp state change irp for a very long time. That driver could be yours in a kmdf callback tied to a pnp state change (kmdf doesn't have system power irp related callbacks) or any other installed driver. If you have a repro, in that 10s window break in and run
!powertriage
!pnpevent
you have to figure out which device is holding onto the lock from the output of either of these extensions