PnP timeout but the watchdog timer thread is holding the locks..?

NTDEV
1

Hello,
I got this odd DRIVER_POWER_STATE_FAILURE bluescreen:

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp subsystem.
Arg2: 00000258, Timeout in seconds.
Arg3: 855d0a70, The thread currently holding on to the Pnp lock.
Arg4: 80d8adf4
…
STACK_TEXT:
80d8add4 82cfe3d3 0000009f 00000004 00000258 nt!KeBugCheckEx+0x1e
80d8ae00 82f536f1 80d8ae4c 82c86117 9f5879b0 nt!PnpBugcheckPowerTimeout+0x57
80d8ae08 82c86117 9f5879b0 9f5879d0 9409747f nt!PopBuildDeviceNotifyListWatchdog+0x16
80d8ae4c 82c860bb 82d52e20 80d8af78 00000001 nt!KiProcessTimerDpcTable+0x50
80d8af38 82c85f78 82d52e20 80d8af78 00000000 nt!KiProcessExpiredTimerList+0x101
80d8afac 82c8416e 00023cde c6fa0731 a115c2a3 nt!KiTimerExpiration+0x25c
80d8aff4 82c8393c 89437710 00000000 00000000 nt!KiRetireDpcList+0xcb
80d8aff8 89437710 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c
WARNING: Frame IP not in any known module. Following frames may be wrong.
82c8393c 00000000 0000001a 00d6850f bb830000 0x89437710

But the thread holding onto the lock is the very same watchdog thread that triggered the BSOD!

kd> !thread 0x855d0a70
THREAD 855d0a70 Cid 0004.0044 Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 0
Not impersonating
DeviceMap 88007830
Owning Process 85564840 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 146652 Ticks: 2 (0:00:00:00.020)
Context Switch Count 112841 NoStackSwap
UserTime 00:00:00.000
KernelTime 00:22:01.690
Win32 Start Address nt!ExpWorkerThread (0x82c89dde)
Stack Init 89437ed0 Current 894376d8 Base 89438000 Limit 89435000 Call 0
Priority 12 BasePriority 12 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
80d8add4 82cfe3d3 0000009f 00000004 00000258 nt!KeBugCheckEx+0x1e
80d8ae00 82f536f1 80d8ae4c 82c86117 9f5879b0 nt!PnpBugcheckPowerTimeout+0x57
80d8ae08 82c86117 9f5879b0 9f5879d0 9409747f nt!PopBuildDeviceNotifyListWatchdog+0x16
80d8ae4c 82c860bb 82d52e20 80d8af78 00000001 nt!KiProcessTimerDpcTable+0x50
80d8af38 82c85f78 82d52e20 80d8af78 00000000 nt!KiProcessExpiredTimerList+0x101
80d8afac 82c8416e 00023cde c6fa0731 a115c2a3 nt!KiTimerExpiration+0x25c
80d8aff4 82c8393c 89437710 00000000 00000000 nt!KiRetireDpcList+0xcb
80d8aff8 89437710 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c (FPO: [Uses EBP] [0,0,1])
WARNING: Frame IP not in any known module. Following frames may be wrong.
82c8393c 00000000 0000001a 00d6850f bb830000 0x89437710

kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ nt!IopDeviceTreeLock (0x82d8d900) Shared 1 owning threads
Threads: 855d0a70-01<*>
KD: Scanning for held locks.

Resource @ nt!PiEngineLock (0x82d8d880) Exclusively owned
Contention Count = 8
NumberOfExclusiveWaiters = 1
Threads: 855d0a70-01<*>
Threads Waiting On Exclusive Access:
855ca4b8

KD: Scanning for held locks…

Resource @ 0x8c7344b0 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 91f83548-01<*>
Threads Waiting On Exclusive Access:
91cbe840

KD: Scanning for held locks…
8201 total locks, 3 locks currently held

What is going on here? It’s not clear to me at all!

2

Unfortunately, the thread backtrace ends at the timer ISR. You need to find out where the interrupted thread’s ESP was and go from there.

3

How do I do that?
In any case, I had a look at KiDispatchInterrupt and it seems to save ebx, ebp, *ebx, and esp in that order. But then, according to kd, KiDispatchInterrupt+0x2C (the return address for the call to KiRetireDpcList) is the second item on the stack. Where are the other three values??

kd> kd
80d8add4 80d8ae00
80d8add8 82cfe3d3 nt!PnpBugcheckPowerTimeout+0x57
80d8addc 0000009f
80d8ade0 00000004
80d8ade4 00000258
80d8ade8 855d0a70
80d8adec 80d8adf4
80d8adf0 80d8ae7c
80d8adf4 00018001
80d8adf8 82d8d740 nt!PnpDeviceCompletionQueue
80d8adfc 82d62c7c nt!ExWorkerQueue+0x3c
80d8ae00 80d8ae08
80d8ae04 82f536f1 nt!PopBuildDeviceNotifyListWatchdog+0x16
80d8ae08 80d8ae4c
80d8ae0c 82c86117 nt!KiProcessTimerDpcTable+0x50
80d8ae10 9f5879b0
80d8ae14 9f5879d0
80d8ae18 9409747f
80d8ae1c 01d12d04
80d8ae20 80d8ae8c
80d8ae24 82d52e20 nt!KiInitialPCR+0x120
80d8ae28 82d54794 nt!KiInitialPCR+0x1a94
80d8ae2c 92b56a60
80d8ae30 00000001
80d8ae34 92b56a60
80d8ae38 80d8ae50
80d8ae3c 82c89a9f nt!KiProcessThreadWaitList+0x3f
80d8ae40 80d8ae8c
80d8ae44 00d52e20
80d8ae48 82d54794 nt!KiInitialPCR+0x1a94
80d8ae4c 80d8af38
80d8ae50 82c860bb nt!KiProcessExpiredTimerList+0x101
80d8ae54 82d52e20 nt!KiInitialPCR+0x120
80d8ae58 80d8af78
80d8ae5c 00000001
80d8ae60 82d54780 nt!KiInitialPCR+0x1a80
80d8ae64 82d55c94 nt!KiInitialPCR+0x2f94
80d8ae68 82d55c90 nt!KiInitialPCR+0x2f90
80d8ae6c 92c0a398
80d8ae70 8c4437d0
80d8ae74 8688f7a9 tcpip!TcpPeriodicTimeoutHandler
80d8ae78 00000000
80d8ae7c 9f5879b0
80d8ae80 82f536db nt!PopBuildDeviceNotifyListWatchdog
80d8ae84 9f5879d0
80d8ae88 86907c20 tcpip!LruContextLoose+0x260
80d8ae8c 86782530 NETIO!WfpSysTimerCallback
80d8ae90 86907bf0 tcpip!LruContextLoose+0x230
80d8ae94 869090a0 tcpip!endpointLruContext+0x260
80d8ae98 86782530 NETIO!WfpSysTimerCallback
80d8ae9c 86909070 tcpip!endpointLruContext+0x230
80d8aea0 85561750
80d8aea4 86782530 NETIO!WfpSysTimerCallback
80d8aea8 85561720
80d8aeac 8c4437d0
80d8aeb0 8688f7a9 tcpip!TcpPeriodicTimeoutHandler
80d8aeb4 00000000
80d8aeb8 80d8aed8
80d8aebc 8634e83a ataport!RemoveActiveDeviceRequest+0x56
80d8aec0 8558d0e8
80d8aec4 ffffffff
80d8aec8 00000000
80d8aecc 80d8aedc
80d8aed0 855940e0
80d8aed4 8634fe49 ataport!IdepCompletedListRemoveCrb+0x11
80d8aed8 92c0a398
80d8aedc 80d8aef8
80d8aee0 863501d1 ataport!IdeSeverCompletedList+0x57
80d8aee4 85595390
80d8aee8 80d8af44
80d8aeec 85594000
80d8aef0 00000000
80d8aef4 80d8af48
80d8aef8 86350689 ataport!IdePortCompletionDpc+0xab
80d8aefc 855940e0
80d8af00 92c0a398
80d8af04 8559409c
80d8af08 86350695 ataport!IdePortCompletionDpc+0xb7
80d8af0c 00000000
80d8af10 8559523c
80d8af14 00000000
80d8af18 855940e0
80d8af1c 80d8af20
80d8af20 00000001
80d8af24 00000000
80d8af28 00000000
80d8af2c 00000000
80d8af30 00000005
80d8af34 00000002
80d8af38 80d8afac
80d8af3c 82c85f78 nt!KiTimerExpiration+0x25c
80d8af40 82d52e20 nt!KiInitialPCR+0x120
80d8af44 80d8af78
80d8af48 00000000
80d8af4c 00000005
80d8af50 855d0a70
80d8af54 82d52e20 nt!KiInitialPCR+0x120
80d8af58 00000008
80d8af5c 00000005
80d8af60 00000000
80d8af64 82d52e20 nt!KiInitialPCR+0x120
80d8af68 00023cde
80d8af6c 82d55c50 nt!KiInitialPCR+0x2f50
80d8af70 000000de
80d8af74 82d55c90 nt!KiInitialPCR+0x2f90
80d8af78 9409747f
80d8af7c 01d12d04
80d8af80 6b635010
80d8af84 00000003
80d8af88 c000fffe
80d8af8c 85594028
80d8af90 00000000
80d8af94 00000000
80d8af98 80000000
80d8af9c 00000000
80d8afa0 00000025
80d8afa4 80d8aff4
80d8afa8 82c84178 nt!KiRetireDpcList+0xd5
80d8afac 80d8aff4
80d8afb0 82c8416e nt!KiRetireDpcList+0xcb
80d8afb4 00023cde
80d8afb8 c6fa0731
80d8afbc a115c2a3
80d8afc0 82d52d00 nt!KiInitialPCR
80d8afc4 00000000
80d8afc8 00000000
80d8afcc 00000008
80d8afd0 676c63c9
80d8afd4 0000039c
80d8afd8 00000000
80d8afdc 00000000
80d8afe0 a115f5f3
80d8afe4 00000336
80d8afe8 00000000
80d8afec 0000039c
80d8aff0 00000000
80d8aff4 89437724
80d8aff8 82c8393c nt!KiDispatchInterrupt+0x2c
80d8affc 89437710
80d8b000 ???
80d8b004 ???
80d8b008 ???
80d8b00c ???
80d8b010 ???
80d8b014 ???
80d8b018 ???
80d8b01c ???
80d8b020 ???
80d8b024 ???
80d8b028 ???
80d8b02c ???
80d8b030 ???
80d8b034 ???
80d8b038 ???
80d8b03c ???
80d8b040 ???
80d8b044 ???
80d8b048 ???
80d8b04c ???
80d8b050 ???
80d8b054 ???
80d8b058 ???
80d8b05c ???
80d8b060 ???
80d8b064 ???
80d8b068 ???
80d8b06c ???
80d8b070 ???
80d8b074 ???
80d8b078 ???
80d8b07c ???
80d8b080 ???
80d8b084 ???
80d8b088 ???
80d8b08c ???
80d8b090 ???
80d8b094 ???
80d8b098 ???
80d8b09c ???
80d8b0a0 ???
80d8b0a4 ???
80d8b0a8 ???
80d8b0ac ???
80d8b0b0 ???
80d8b0b4 ???
80d8b0b8 ???
80d8b0bc ???
80d8b0c0 ???
80d8b0c4 ???
80d8b0c8 ???
80d8b0cc ???
80d8b0d0 ???
80d8b0d4 ???
80d8b0d8 ???
80d8b0dc ???
80d8b0e0 ???
80d8b0e4 ???
80d8b0e8 ???
80d8b0ec ???
80d8b0f0 ???
80d8b0f4 ???
80d8b0f8 ???
80d8b0fc ???
80d8b100 ???
80d8b104 ???
80d8b108 ???
80d8b10c ???
80d8b110 ???
80d8b114 ???
80d8b118 ???
80d8b11c ???
80d8b120 ???
80d8b124 ???
80d8b128 ???
80d8b12c ???
80d8b130 ???
80d8b134 ???
80d8b138 ???
80d8b13c ???
80d8b140 ???
80d8b144 ???
80d8b148 ???
80d8b14c ???
80d8b150 ???
80d8b154 ???
80d8b158 ???
80d8b15c ???
80d8b160 ???
80d8b164 ???
80d8b168 ???
80d8b16c ???
80d8b170 ???
80d8b174 ???
80d8b178 ???
80d8b17c ???
80d8b180 ???
80d8b184 ???
80d8b188 ???
80d8b18c ???
80d8b190 ???
80d8b194 ???
80d8b198 ???
80d8b19c ???
80d8b1a0 ???
80d8b1a4 ???
80d8b1a8 ???
80d8b1ac ???
80d8b1b0 ???
80d8b1b4 ???
80d8b1b8 ???
80d8b1bc ???
80d8b1c0 ???
80d8b1c4 ???
80d8b1c8 ???
80d8b1cc ???
80d8b1d0 ???

4

On the x86 you can pluck the saved ESP off the stack, it’s the first “Args to Child” in the KiRetireDpcList frame. Try:

dps 89437710

And start looking for a call chain. I suspect that you’re going to find the thread in an infinite loop, according to the output it has used 22 minutes of CPU time.

-scott
OSR
@OSRDrivers

5

Wow thanks, I did not know about the dps command. This is incredibly useful.

Anyway,

kd> dps 89437710
89437710 ffffffff
89437714 89437724
89437718 00000000
8943771c 82c1742f hal!HalpDispatchInterrupt2ndEntry+0x21
89437720 00000000
89437724 894377a0
89437728 99a978a9 USBD!USBD_ParseDescriptors+0x21
8943772c badb0d00
89437730 00000000
89437734 82c83a30 nt!KiDispatchInterrupt+0x120
89437738 00000000
8943773c 82c17435 hal!HalpDispatchInterrupt2ndEntry+0x27
89437740 00000000
89437744 894377c0
89437748 99a978ed USBD!USBD_ParseConfigurationDescriptorEx+0x25
8943774c badb0d00
89437750 00000000
89437754 82c17d94 hal!Halp8254ClockInterrupt+0xf0
89437758 9f6487b5
8943775c 82c08901 hal!HalEndSystemInterrupt+0x9
89437760 8c7c920b
89437764 8c7c9008
89437768 00000000
8943776c 894377f4
89437770 89437c80
89437774 badb0d00
89437778 ffffffff
8943777c 00000002
89437780 8c7c9008
89437784 894377a0
89437788 00000000
8943778c 99a978a9 USBD!USBD_ParseDescriptors+0x21

Just taking a wild stab in the dark:

kd> .trap 89437724
ErrCode = 00000000
eax=00000000 ebx=8c7c9008 ecx=8c7c9008 edx=8c7c920b esi=00000002 edi=ffffffff
eip=99a978a9 esp=89437798 ebp=894377a0 iopl=0 nv up ei ng nz ac po cy
cs=0008 ss=0010 ds=8901 es=87b5 fs=0d00 gs=7d94 efl=00000293
USBD!USBD_ParseDescriptors+0x21:
99a978a9 8a19 mov bl,byte ptr [ecx] ds:8901:9008=??

kd> kb
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
894377a0 99a978e5 8c7c9008 00000203 8c7c9008 USBD!USBD_ParseDescriptors+0x21
894377c0 a8ec2f16 8c7c9008 8c7c9008 ffffffff USBD!USBD_ParseConfigurationDescriptorEx+0x1d
894377f4 a8ec030f 8c7c9008 92cd64e4 a8edd600 usbvideo!GetSpecVersion+0x26
89437818 a8ebf74d 92cd64e4 918bc2b0 92cd6478 usbvideo!StartUSBVideoDevice+0x23d
89437830 863de0d4 92cd64e4 9069ee28 00000000 usbvideo!USBVideoPnpStart+0x4f
8943785c 863d8540 9069ee28 9069ef70 9069ee28 ks!CKsDevice::PnpStart+0x72
89437878 82f5a4d9 918bc1f8 9069ee28 9069ef70 ks!CKsDevice::DispatchPnp+0x2d2
8943789c 82c5d13d 82de5bd6 89437920 918bc1f8 nt!IovCallDriver+0x73
894378b0 82de5bd6 00000000 92fde8a8 91dfee28 nt!IofCallDriver+0x1b
894378cc 82c48856 894378fc 82c48605 91dfee28 nt!PnpAsynchronousCall+0x92
89437930 82de8bc4 82c48605 91dfee28 92c91538 nt!PnpStartDevice+0xdb
8943798c 82de8a8d 91dfee28 0000002d 00000000 nt!PnpStartDeviceNode+0x12c
894379a8 82de0eec 00000000 00000000 91a8adb0 nt!PipProcessStartPhase1+0x62
89437ba4 82dd798e 91870008 91a8adb0 89437bd0 nt!PipProcessDevNodeTree+0x188
89437bd8 82c4840a 82d8b7a0 855d0a70 82d62c7c nt!PiProcessReenumeration+0x74
89437c00 82c89eeb 00000000 00000000 855d0a70 nt!PnpDeviceActionWorker+0x224
89437c50 82e19854 00000001 501e546c 00000000 nt!ExpWorkerThread+0x10d
89437c90 82cb87b9 82c89dde 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

Did I do it right? How can I be sure this was the context it was executing in before the interrupt? This could be very misleading if it’s bogus.

6

Considering this stack is processing a pno start which holds the power state /pnp lock which leads to the 9f timeout, I think you have the right stack. Nothing in the stack looks suspicious though, just normal USB descriptor parsing

Sent from Outlook Mailhttp: for Windows 10 phone

From: xxxxx@secureworks.com
Sent: Thursday, December 3, 2015 5:51 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PnP timeout but the watchdog timer thread is holding the locks…?

Wow thanks, I did not know about the dps command. This is incredibly useful.

Anyway,

kd> dps 89437710
89437710 ffffffff
89437714 89437724
89437718 00000000
8943771c 82c1742f hal!HalpDispatchInterrupt2ndEntry+0x21
89437720 00000000
89437724 894377a0
89437728 99a978a9 USBD!USBD_ParseDescriptors+0x21
8943772c badb0d00
89437730 00000000
89437734 82c83a30 nt!KiDispatchInterrupt+0x120
89437738 00000000
8943773c 82c17435 hal!HalpDispatchInterrupt2ndEntry+0x27
89437740 00000000
89437744 894377c0
89437748 99a978ed USBD!USBD_ParseConfigurationDescriptorEx+0x25
8943774c badb0d00
89437750 00000000
89437754 82c17d94 hal!Halp8254ClockInterrupt+0xf0
89437758 9f6487b5
8943775c 82c08901 hal!HalEndSystemInterrupt+0x9
89437760 8c7c920b
89437764 8c7c9008
89437768 00000000
8943776c 894377f4
89437770 89437c80
89437774 badb0d00
89437778 ffffffff
8943777c 00000002
89437780 8c7c9008
89437784 894377a0
89437788 00000000
8943778c 99a978a9 USBD!USBD_ParseDescriptors+0x21

Just taking a wild stab in the dark:

kd> .trap 89437724
ErrCode = 00000000
eax=00000000 ebx=8c7c9008 ecx=8c7c9008 edx=8c7c920b esi=00000002 edi=ffffffff
eip=99a978a9 esp=89437798 ebp=894377a0 iopl=0 nv up ei ng nz ac po cy
cs=0008 ss=0010 ds=8901 es=87b5 fs=0d00 gs=7d94 efl=00000293
USBD!USBD_ParseDescriptors+0x21:
99a978a9 8a19 mov bl,byte ptr [ecx] ds:8901:9008=??

kd> kb
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
894377a0 99a978e5 8c7c9008 00000203 8c7c9008 USBD!USBD_ParseDescriptors+0x21
894377c0 a8ec2f16 8c7c9008 8c7c9008 ffffffff USBD!USBD_ParseConfigurationDescriptorEx+0x1d
894377f4 a8ec030f 8c7c9008 92cd64e4 a8edd600 usbvideo!GetSpecVersion+0x26
89437818 a8ebf74d 92cd64e4 918bc2b0 92cd6478 usbvideo!StartUSBVideoDevice+0x23d
89437830 863de0d4 92cd64e4 9069ee28 00000000 usbvideo!USBVideoPnpStart+0x4f
8943785c 863d8540 9069ee28 9069ef70 9069ee28 ks!CKsDevice::PnpStart+0x72
89437878 82f5a4d9 918bc1f8 9069ee28 9069ef70 ks!CKsDevice::DispatchPnp+0x2d2
8943789c 82c5d13d 82de5bd6 89437920 918bc1f8 nt!IovCallDriver+0x73
894378b0 82de5bd6 00000000 92fde8a8 91dfee28 nt!IofCallDriver+0x1b
894378cc 82c48856 894378fc 82c48605 91dfee28 nt!PnpAsynchronousCall+0x92
89437930 82de8bc4 82c48605 91dfee28 92c91538 nt!PnpStartDevice+0xdb
8943798c 82de8a8d 91dfee28 0000002d 00000000 nt!PnpStartDeviceNode+0x12c
894379a8 82de0eec 00000000 00000000 91a8adb0 nt!PipProcessStartPhase1+0x62
89437ba4 82dd798e 91870008 91a8adb0 89437bd0 nt!PipProcessDevNodeTree+0x188
89437bd8 82c4840a 82d8b7a0 855d0a70 82d62c7c nt!PiProcessReenumeration+0x74
89437c00 82c89eeb 00000000 00000000 855d0a70 nt!PnpDeviceActionWorker+0x224
89437c50 82e19854 00000001 501e546c 00000000 nt!ExpWorkerThread+0x10d
89437c90 82cb87b9 82c89dde 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

Did I do it right? How can I be sure this was the context it was executing in before the interrupt? This could be very misleading if it’s bogus.

—
NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:></http:>

7

You have hung the PnP worker thread, my congratulations.

Some of your MJ_PNP processing was hung.

What is its stack (not the DPC stack which fired a bugcheck)?

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hello,
> I got this odd DRIVER_POWER_STATE_FAILURE bluescreen:
>
>
>
> DRIVER_POWER_STATE_FAILURE (9f)
> A driver is causing an inconsistent power state.
> Arguments:
> Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp subsystem.
> Arg2: 00000258, Timeout in seconds.
> Arg3: 855d0a70, The thread currently holding on to the Pnp lock.
> Arg4: 80d8adf4
> …
> STACK_TEXT:
> 80d8add4 82cfe3d3 0000009f 00000004 00000258 nt!KeBugCheckEx+0x1e
> 80d8ae00 82f536f1 80d8ae4c 82c86117 9f5879b0 nt!PnpBugcheckPowerTimeout+0x57
> 80d8ae08 82c86117 9f5879b0 9f5879d0 9409747f nt!PopBuildDeviceNotifyListWatchdog+0x16
> 80d8ae4c 82c860bb 82d52e20 80d8af78 00000001 nt!KiProcessTimerDpcTable+0x50
> 80d8af38 82c85f78 82d52e20 80d8af78 00000000 nt!KiProcessExpiredTimerList+0x101
> 80d8afac 82c8416e 00023cde c6fa0731 a115c2a3 nt!KiTimerExpiration+0x25c
> 80d8aff4 82c8393c 89437710 00000000 00000000 nt!KiRetireDpcList+0xcb
> 80d8aff8 89437710 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 82c8393c 00000000 0000001a 00d6850f bb830000 0x89437710
>
>
>
> But the thread holding onto the lock is the very same watchdog thread that triggered the BSOD!
>
>
>
> kd> !thread 0x855d0a70
> THREAD 855d0a70 Cid 0004.0044 Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 0
> Not impersonating
> DeviceMap 88007830
> Owning Process 85564840 Image: System
> Attached Process N/A Image: N/A
> Wait Start TickCount 146652 Ticks: 2 (0:00:00:00.020)
> Context Switch Count 112841 NoStackSwap
> UserTime 00:00:00.000
> KernelTime 00:22:01.690
> Win32 Start Address nt!ExpWorkerThread (0x82c89dde)
> Stack Init 89437ed0 Current 894376d8 Base 89438000 Limit 89435000 Call 0
> Priority 12 BasePriority 12 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 80d8add4 82cfe3d3 0000009f 00000004 00000258 nt!KeBugCheckEx+0x1e
> 80d8ae00 82f536f1 80d8ae4c 82c86117 9f5879b0 nt!PnpBugcheckPowerTimeout+0x57
> 80d8ae08 82c86117 9f5879b0 9f5879d0 9409747f nt!PopBuildDeviceNotifyListWatchdog+0x16
> 80d8ae4c 82c860bb 82d52e20 80d8af78 00000001 nt!KiProcessTimerDpcTable+0x50
> 80d8af38 82c85f78 82d52e20 80d8af78 00000000 nt!KiProcessExpiredTimerList+0x101
> 80d8afac 82c8416e 00023cde c6fa0731 a115c2a3 nt!KiTimerExpiration+0x25c
> 80d8aff4 82c8393c 89437710 00000000 00000000 nt!KiRetireDpcList+0xcb
> 80d8aff8 89437710 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c (FPO: [Uses EBP] [0,0,1])
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 82c8393c 00000000 0000001a 00d6850f bb830000 0x89437710
>
>
>
>
> kd> !locks
> DUMP OF ALL RESOURCE OBJECTS
> KD: Scanning for held locks…
>
> Resource @ nt!IopDeviceTreeLock (0x82d8d900) Shared 1 owning threads
> Threads: 855d0a70-01<>
> KD: Scanning for held locks.
>
> Resource @ nt!PiEngineLock (0x82d8d880) Exclusively owned
> Contention Count = 8
> NumberOfExclusiveWaiters = 1
> Threads: 855d0a70-01<>
> Threads Waiting On Exclusive Access:
> 855ca4b8
>
> KD: Scanning for held locks…
>
> Resource @ 0x8c7344b0 Shared 1 owning threads
> Contention Count = 1
> NumberOfExclusiveWaiters = 1
> Threads: 91f83548-01<*>
> Threads Waiting On Exclusive Access:
> 91cbe840
>
> KD: Scanning for held locks…
> 8201 total locks, 3 locks currently held
>
>
>
> What is going on here? It’s not clear to me at all!
>
>