Run !devstack and then !object on each device object in the stack. Perhaps the handle counts are on named objects higher up.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@cspeed.com
Sent: Monday, December 3, 2012 2:17 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PDO for AVStream device stuck in WdfDevStatePnpFailedWaitForRemove state
I’m not certain what exactly to look for, but there appear to be zero handles to the child PDO (note that the addresses here are different because it’s a new session and I’m looking at the WDM device objects now):
0: kd> !object fffffa80066d7d30
Object: fffffa80066d7d30 Type: (fffffa80048cfa20) Device
ObjectHeader: fffffa80066d7d00 (new version)
HandleCount: 0 PointerCount: 3
Directory Object: fffff8a000014060 Name: 00000043
0: kd> !devobj fffffa80066d7d30
Device object (fffffa80066d7d30) is for:
00000043 \Driver\xxxxx DriverObject fffffa8006683e60 Current Irp 00000000 RefCount 2 Type 00000022 Flags 00003044 Dacl fffff9a1003b3c81 DevExt fffffa8006684d50 DevObjExt fffffa80066d7ea8 DevNode fffffa80066cd0c0 ExtensionFlags (0x00000004) DOE_REMOVE_PENDING AttachedDevice (Upper) fffffa80076bfe10 \Driver\avshws Device queue is not busy.
Also, the child’s FDO (AVSHWS) also shows zero handles:
0: kd> !object fffffa80076bfe10
Object: fffffa80076bfe10 Type: (fffffa80048cfa20) Device
ObjectHeader: fffffa80076bfde0 (new version)
HandleCount: 0 PointerCount: 1
0: kd> !devobj fffffa80076bfe10
Device object (fffffa80076bfe10) is for:
\Driver\avshws DriverObject fffffa8007b16060 Current Irp 00000000 RefCount 0 Type 0000002f Flags 00002000 Dacl fffff9a10016a641 DevExt fffffa80076bff80 DevObjExt fffffa80076bff88 ExtensionFlags (0x00000804) DOE_REMOVE_PENDING
Unknown flags 0x00000800 AttachedDevice (Upper) fffffa800669bd10 \Driver\ksthunk AttachedTo (Lower) fffffa80066d7d30 \Driver\xxxxx Device queue is not busy.
Given this information, is there anything that I can do to aid in the clean teardown of the driver stack from this state? Is there anything that I can do as the driver developer to play more nicely with existing capture applications and/or mitigate the risk of falling into this state?
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
The stack looks to be pretty limited, with just one other device atop the AVSHWS device:
0: kd> !devstack fffffa80066d7d30
!DevObj !DrvObj !DevExt ObjectName
fffffa800669bd10 \Driver\ksthunk fffffa800669be60 0000006b
fffffa80076bfe10 \Driver\avshws fffffa80076bff80
fffffa80066d7d30 \Driver***** fffffa8006684d50 00000043
!DevNode fffffa80066cd0c0 :
DeviceInst is “AVStream*****\5&167020b0&3&Default”
ServiceName is “avshws”
Going up the device stack, I’m not seeing any handles:
0: kd> !object fffffa80066d7d30
Object: fffffa80066d7d30 Type: (fffffa80048cfa20) Device
ObjectHeader: fffffa80066d7d00 (new version)
HandleCount: 0 PointerCount: 3
Directory Object: fffff8a000014060 Name: 00000043
0: kd> !object fffffa80076bfe10
Object: fffffa80076bfe10 Type: (fffffa80048cfa20) Device
ObjectHeader: fffffa80076bfde0 (new version)
HandleCount: 0 PointerCount: 1
0: kd> !object fffffa800669bd10
Object: fffffa800669bd10 Type: (fffffa80048cfa20) Device
ObjectHeader: fffffa800669bce0 (new version)
HandleCount: 0 PointerCount: 2
Directory Object: fffff8a000014060 Name: 0000006b
Any idea what could be holding things up?
On an unrelated note, do you know why this thread was flagged as spam so that I can avoid it in the future? I replaced the x’s with *'s in this post in case that was the reason.
Thanks.