[wdmaudiodev] Driver Verifier Deadlock on x64 System
- From: Art Edwards <ntdeveloper@xxxxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Fri, 18 Nov 2005 15:37:43 -0500
I am trying to get an x64 version of an audio miniport driver to pass the
HCT Driver Verifier test.
The test runs for a while and locks up. If I run the test with the
debugger attached, it can run without locking up. However, that won't
suffice for WHQL. If I run it without the debugger attached, it will lock
up. Then, when I attach the debugger (and load the symbols), I find the
following:
0: kd> !running -i -t
System Processors 3 (affinity mask)
Idle Processors 0
Prcb Current Next
0 fffff80001189180 fffffadfe7752040 ................
Child-SP RetAddr Call Site
fffff800`003cdaf8 fffff800`01081c55 nt!RtlpBreakWithStatusInstruction
fffff800`003cdb00 fffff800`01002851 nt!KdCheckForDebugBreak+0xb2
fffff800`003cdb40 fffff800`010526c0 nt!KeUpdateRunTime+0x19e
fffff800`003cdb70 fffff800`008141e8 nt!KeUpdateSystemTime+0xf0
fffff800`003cdba0 fffff800`010517d9 hal!HalpClockInterrupt+0xa8
fffff800`003cdbd0 fffff800`0102e974 nt!KiInterruptDispatchNoLock+0x119
fffff800`003cdd68 fffff800`013c8c54 nt!KxWaitForSpinLockAndAcquire+0x4
fffff800`003cdd70 fffffadf`e375f9a1
nt!VerifierKeAcquireSpinLockRaiseToDpc+0x23
fffff800`003cddb0 fffffadf`e3762a02 portcls!CIrpStream::GetPacketInfo+0x51
fffff800`003cdde0 fffffadf`e376237d portcls!CPackerMXF::ProcessQueues+0x42
fffff800`003cdf00 fffffadf`e375c63f
portcls!CPortPinDMus::RequestService+0x7d
fffff800`003cdf30 fffff800`010530d4 portcls!CServiceGroup::ServiceDpc+0x3f
fffff800`003cdf70 fffff800`01054a8f nt!KiRetireDpcList+0x14b
fffff800`003ce000 00000000`00000000 nt!KiDispatchInterrupt+0x4f
1 fffffadfe447b180 fffffadfe6a0c040 ................
Child-SP RetAddr Call Site
fffffadf`e481dec8 fffff800`013c8b92 nt!KxWaitForSpinLockAndAcquire+0x4
fffffadf`e481ded0 fffffadf`e375c628
nt!VerifierKeAcquireSpinLockAtDpcLevel+0x51
fffffadf`e481df10 fffff800`010530d4 portcls!CServiceGroup::ServiceDpc+0x28
fffffadf`e481df50 fffff800`01054a8f nt!KiRetireDpcList+0x14b
fffffadf`e481dfe0 00000000`00000000 nt!KiDispatchInterrupt+0x4f
After looking through a bit of disassembly, I can say that:
Processor 1 is waiting on a spinlock that protects a list of ServiceSink
objects with their head in a portcls!CServiceGroup object.
The aforementioned spinlock has already been acquired by processor
0. Having acquired ownership of that lock, processor 0 has proceeded on to
portcls!CIrpStream::GetPacketInfo. At this point it is waiting to obtain
ownership of another spinlock at offset 0xd0 in the object pointed to by
its "this" pointer.
However, that lock has already been claimed by someone else. I have been
unable to determine whether any one else is holding the lock. I suspect it
may have been orphaned. Is that possible ?
I thought the Driver Verifier's deadlock detection might offer some
clues. But, according to a recent "Hector's Memos" installment in the NT
Insider, deadlock detection does not work on x64 "single CPU" systems.
I have tried running the x86 build of the same driver on x86 SMP
machines. So far, it passes consistently on one of them. At this time,
I'm still setting the 2nd x86 SMP machine up to run the test.
Has anyone else confronted something like this. Or, does anyone (esp. from
MS) know of problems in x64 builds of portcls.sys that might lead to
something like this ?
Art
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
Other related posts:
- » [wdmaudiodev] Driver Verifier Deadlock on x64 System