Question
278 views

DPC Watchdog Violation

ConnorMooney asked on

Hello!

 I've recently upgraded my pc for the purpose of gaming and such. Every couple of boots before I log in, the computer freezes for a couple and seconds and shows a BSOD with the error "DPC_Watchdog_Violaton." I've read that this can be caused by out of date drivers and such. I went through my device manager and checked if everything had up to date drivers. After that, I still receive the error ocassionally and I don't want it to cause any issues. Is there anything else I can do to make sure this is fixed? Any help would be greatly appreciated!

 Thank you,

Connor Mooney

*** Email address is removed for privacy ***

1 person had this question

Abuse history


The answered status icon Answer
Patrick Barker replied on

Thanks very much, that worked just fine!

The attached DMP file is of the DPC_WATCHDOG_VIOLATION (133) bug check.

This bug check indicates that the DPC watchdog executed, either because it detected a single long-running deferred procedure call (DPC), or because the system spent a prolonged time at an interrupt request level (IRQL) of DISPATCH_LEVEL or above.

BugCheck 133, {0, 501, 500, 0}

This specific DPC has run for 0x501 ticks, when the limit was 0x500.

1: kd> knL
 # Child-SP          RetAddr           Call Site
00 fffff880`009ff2f8 fffff800`921def4b nt!KeBugCheckEx
01 fffff880`009ff300 fffff800`920a3774 nt! ?? ::FNODOBFM::`string'+0x145a4
02 fffff880`009ff380 fffff800`92773eca nt!KeUpdateTime+0x2ec
03 fffff880`009ff560 fffff800`9205801e hal!HalpTimerClockInterrupt+0x86
04 fffff880`009ff590 fffff800`920a919c nt!KiInterruptDispatchLBControl+0x1ce
05 fffff880`009ff720 fffff800`920e39c9 nt!KxWaitForLockOwnerShip+0x30
06 fffff880`009ff750 fffff880`036fef43 nt!IoAcquireCancelSpinLock+0x59
07 fffff880`009ff780 fffff880`036fc396 netbt!MSnodeCompletion+0x393
08 fffff880`009ff820 fffff800`920881ea netbt!TimerExpiry+0x66
09 fffff880`009ff870 fffff800`92086655 nt!KiProcessExpiredTimerList+0x22a
0a fffff880`009ff9a0 fffff800`92088668 nt!KiExpireTimerTable+0xa9
0b fffff880`009ffa40 fffff800`92087a06 nt!KiTimerExpiration+0xc8
0c fffff880`009ffaf0 fffff800`920889ba nt!KiRetireDpcList+0x1f6
0d fffff880`009ffc60 00000000`00000000 nt!KiIdleLoop+0x5a

The offending driver appears to be netbt.sys which is the MBT Transport driver (system driver). It called into nt!IoAcquireCancelSpinLock.

Let’s view the driver’s unassembled DPC routine:

1: kd> ub fffff880`036fef43
netbt!MSnodeCompletion+0x36a:
fffff880`036fef1a 48897008        mov     qword ptr [rax+8],rsi
fffff880`036fef1e 4889355b760300  mov     qword ptr [netbt!TimerQ (fffff880`03736580)],rsi
fffff880`036fef25 488935b4830300  mov     qword ptr [netbt!LmHostQueries (fffff880`037372e0)],rsi
fffff880`036fef2c 498b7518        mov     rsi,qword ptr [r13+18h]
fffff880`036fef30 4885f6          test    rsi,rsi
fffff880`036fef33 0f84b7020000    je      netbt!MSnodeCompletion+0x63a (fffff880`036ff1f0)
fffff880`036fef39 488d4e45        lea     rcx,[rsi+45h]
fffff880`036fef3d ff15fd030300    call    qword ptr [netbt!_imp_IoAcquireCancelSpinLock (fffff880`0372f340)]

We have IoAcquireCancelSpinLock. This routine synchronizes cancelable-state transitions for IRPs in a multiprocessor-safe way. It appears that a driver is holding the cancel lock and not allowing it to leave this state. We can also see this is the case by further disassembling:

1: kd> u fffff880`036fef43
netbt!MSnodeCompletion+0x393:
fffff880`036fef43 44387644        cmp     byte ptr [rsi+44h],r14b
fffff880`036fef47 0f8588c20200    jne     netbt! ?? ::FNODOBFM::`string'+0x5d36 (fffff880`0372b1d5)
fffff880`036fef4d 488b86b8000000  mov     rax,qword ptr [rsi+0B8h]
fffff880`036fef54 418bee          mov     ebp,r14d
fffff880`036fef57 80480301        or      byte ptr [rax+3],1
fffff880`036fef5b 488d05be2f0200  lea     rax,[netbt!NbtCancelWaitForLmhSvcIrp (fffff880`03721f20)]
fffff880`036fef62 48874668        xchg    rax,qword ptr [rsi+68h]
fffff880`036fef66 0fb64e45        movzx   ecx,byte ptr [rsi+45h]

Now, with all of this said, we'll need to take a look at the different processors to see what's going on within their stacks at the time of the crash to determine what driver may be holding onto the cancel lock.

I'll save post space and tell you that processor 0 was sleeping, and 2 is interesting.. so let's have a look:

2: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`172702f0 fffff800`920b14e5 : 00000000`00000002 fffffa80`07694b90 fffffa80`0a3e06e0 fffffa80`0962b160 : nt!KxWaitForSpinLockAndAcquire+0x23
fffff880`17270320 fffff880`036fe634 : fffffa80`0fe1a840 00000000`00000000 00000000`00000001 fffff880`5874624e : nt!KeAcquireSpinLockRaiseToDpc+0x35
fffff880`17270350 fffff800`92090ee0 : fffffa80`07694b90 fffff880`17270429 fffffa80`07694b00 fffffa80`09c759f0 : netbt!TdiSendDatagramCompletion+0x174
fffff880`172703b0 fffff880`036ce35d : fffffa80`08f56a90 00000000`00000002 00000000`00000000 00000000`42786454 : nt!IopfCompleteRequest+0x440
fffff880`17270490 fffff880`01a6a842 : 00000000`00000000 fffffa80`13d817d0 00000000`00000000 fffffa80`11ba46c0 : tdx!TdxMessageTlRequestComplete+0xed
fffff880`172704e0 fffff880`01961291 : 00000000`00000000 00000000`00000001 00000000`00000001 00000000`00000000 : tcpip!UdpSendMessagesDatagramsComplete+0xe2
fffff880`17270540 fffff880`01a7d02b : 00000014`00000000 00000000`00000001 fffffa80`150ad340 fffffa80`09d70680 : NETIO!NetioDereferenceNetBufferListChain+0x121
fffff880`17270610 fffff880`0186b3e5 : 00000000`00000001 fffffa80`0a6bf010 00000000`00000001 00000000`00000000 : tcpip!FlSendNetBufferListChainComplete+0x5b
fffff880`17270640 fffff880`0186b89e : fffffa80`115441a0 fffffa80`13d815c0 fffff880`00000001 00000000`00000002 : ndis!ndisMSendCompleteNetBufferListsInternal+0x135
fffff880`172706f0 fffff880`0186bb7f : fffffa80`13d815c0 00000000`00000000 fffffa80`1379a3e0 fffff800`920cdc08 : ndis!ndisInvokeNextSendCompleteHandler+0x11e
*** ERROR: Module load completed but symbols could not be loaded for Hamdrv.sys
fffff880`17270790 fffff880`179c53ce : fffffa80`13d815c0 fffff880`19ef78a0 fffffa80`08b77000 fffffa80`08b77040 : ndis!NdisMSendNetBufferListsComplete+0x9f
fffff880`172707f0 fffff880`179c405d : fffffa80`13d81720 fffffa80`08b77040 fffffa80`08b77040 fffffa80`0bddf380 : Hamdrv+0x33ce
fffff880`17270830 fffff880`018eb068 : 00000000`00000000 00000000`00000002 fffff680`00008fa0 fffffa80`0000006e : Hamdrv+0x205d
fffff880`17270890 fffff800`92470868 : 00000000`00000000 fffffa80`09f2b900 fffffa80`09f2b900 fffff880`17270929 : ndis!ndisDummyIrpHandler+0x50
fffff880`172708c0 fffff800`924a0513 : 00000000`00000000 00000000`00000001 fffffa80`09f2b900 fffffa80`09f2b900 : nt!IopSynchronousServiceTail+0x158
fffff880`17270990 fffff800`9205e453 : fffff880`17270ad8 00000000`00000290 00000000`00000000 00000000`011f2810 : nt!NtReadFile+0x661
fffff880`17270a90 000007f9`e6ac2c4a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`17270b00)
00000000`016afc28 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x000007f9`e6ac2c4a

It appears that Hamdrv.sys is the problematic driver. This is the LogMeIn Hamachi Virtual Miniport driver. With this said, either be sure your LogMeIn software is fully up to date, or uninstall it.

Regards,

Patrick

Debugger/Reverse Engineer.
1 person found this helpful

Abuse history


progress