> Thread 0x94A74B40 is waiting for all inflight requests on WDFQUEUE
0x7CCA5D80 to be acknowledged
!wdfkd.wdfqueue 0x7CCA5D80
(where 0x7CCA5D80 comes from the debugger output mentioned above) will
list the inflight I/O for the queue that is blocked.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Friday, November 17, 2006 7:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Why does !wdfkd.wdfdevicequeues shows number of
queues as “0”
One basic misconception shows up at first glance:
(1) The OS basic driver model is WDM. The first messages you are seeing
come from the OS and give addresses of WDM objects. The power manager
has to do this- this is the first OS build with KMDF integrated, and to
expect us to have integrated it so thoroughly that every debug spewed
error message out of the OS that happens to involve a KMDF driver will
give you KMDF handles instead of WDM object addresses is to ask to have
delayed the ship of Vista even longer than it already was. Not to
mention an impossible sales job convincing devs with a heavy workload of
agressively planned and scheduled tasks to go to all that extra effort
for a technology representing a fraction of the current driver set… I
believe we’ve done what we can with KMDF, but in the end, our whole team
(test/dev/pm) is less than a dozen people in a group containing hundreds
if not thousands.
(2) A device object pointer and a WDFDEVICE are not and probably never
will be [for the foreseeable future] the same thing.
So the problem that led to all that venomous spew is that you gave a WDM
DEVICE_OBJECT pointer to wdfdevicequeues, when it should have been the
WDFDEVICE handle. The output from that command means nothing. GIGO.
You can use !devobj 8beeb5f8 to get the device extension, then
!wdfdevext to see the WDFDEVICE handle.
Or since you already have a WDF log dump, you can probably just pull the
WDFDEVICE handle out of one of the earlier messages.
The mangled output from !wdfqueue I’m not certain of, but since you’ve
cherry-picked parts of the debug output from a longer session, my best
guess is that what I’m seeing doesn’t correctly represent the situation.
I can tell you’re trying to get the right info out here in the attempt
to get your answer, but this isn’t quite it. Maybe Doron could solve
this, but there’s only one of him on the whole planet, and he has to
sleep sometime. Us mere mortals need a bit more info.
For instance, what’s the stack for the thread listed (!thread 94a74840)?
If it’s no longer waiting, then the driver may have gone far enough in
teardown to destroy the queue, but without the correct output from the
previous command, and not being thoroughly familiar with your driver,
there’s no way for me or anyone else to know if you’ve got other queues
not torn down and not having completed requests.
I won’t say there’s not a KMDF bug here (because no test process is ever
perfect), but it isn’t likely.
As before, you can always email me [even to ask me to not publicly
humiliate you, although that’s actually not my intent, and I apologize
if it seems that way]. The entire log dump or session output [big as
that may be] would be fine.
I’m sure I’ll be sorry I posted some of this at some point, but I need
to get back to work, so .
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer