Thanks!
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.
Code:
6: kd> knL
# Child-SP RetAddr Call Site
00 ffffd001`4df71c98 fffff800`2620bad6 nt!KeBugCheckEx
01 ffffd001`4df71ca0 fffff800`2612c678 nt! ?? ::FNODOBFM::`string'+0x2f626
02 ffffd001`4df71d30 fffff800`2601067f nt!KeClockInterruptNotify+0x788
03 ffffd001`4df71f40 fffff800`26147363 hal!HalpTimerClockInterrupt+0x4f
04 ffffd001`4df71f70 fffff800`261cd42a nt!KiCallInterruptServiceRoutine+0xa3
05 ffffd001`4df71fb0 fffff800`261cd80f nt!KiInterruptSubDispatchNoLockNoEtw+0xea
06 ffffd001`4df3f630 fffff800`2611dc20 nt!KiInterruptDispatchLBControl+0x11f
07 ffffd001`4df3f7c0 fffff800`26144512 nt!KxWaitForLockOwnerShip+0x30
08 ffffd001`4df3f7f0 fffff800`2614405f nt!IoAcquireCancelSpinLock+0x56
09 ffffd001`4df3f820 fffff801`d3a01388 nt!IoStartPacket+0x47
0a ffffd001`4df3f860 fffff801`d259ecd1 USBSTOR!USBSTOR_Scsi+0x259
0b ffffd001`4df3f8e0 fffff801`d245423c SamsungRapidDiskFltr+0x1cd1
0c ffffd001`4df3f910 fffff801`d2453df5 CLASSPNP!ClasspSendMediaStateIrp+0x10c
0d ffffd001`4df3f960 fffff800`260d1810 CLASSPNP!ClasspTimerTick+0x65
0e ffffd001`4df3f9b0 fffff800`261cfaea nt!KiRetireDpcList+0x4f0
0f ffffd001`4df3fc60 00000000`00000000 nt!KiIdleLoop+0x5a
^^ Samsung RAPID Mode Disk Filter driver.
In the stack, we can see we're acquiring a cancel spin lock, waiting for lock ownership, and then we have an interrupt due to no lock, then the clock interrupt.
Code:
0: kd> knL
# Child-SP RetAddr Call Site
00 ffffd000`21711a40 fffff800`26147622 nt!KxWaitForSpinLockAndAcquire+0x18
01 ffffd000`21711a70 fffff801`d41c4604 nt!KeAcquireSpinLockRaiseToDpc+0x32
02 ffffd000`21711aa0 fffff801`d41c3d57 Hamdrv+0x3604
03 ffffd000`21712190 fffff801`d2c6da21 Hamdrv+0x2d57
04 ffffd000`217121e0 fffff801`d2f4b4db ndis!NdisSendNetBufferLists+0x551
05 ffffd000`217123d0 fffff801`d2f48d64 tcpip!IppFragmentPackets+0x4eb
06 ffffd000`21712510 fffff801`d2f484b5 tcpip!IppDispatchSendPacketHelper+0x94
07 ffffd000`217126a0 fffff801`d2f47662 tcpip!IppPacketizeDatagrams+0x2d5
08 ffffd000`21712840 fffff801`d2f550b2 tcpip!IppSendDatagramsCommon+0x4a2
09 ffffd000`21712a30 fffff801`d2f5581a tcpip!UdpSendMessagesOnPathCreation+0x472
0a ffffd000`21712e70 fffff801`d2f1070c tcpip!UdpSendMessages+0x1da
0b ffffd000`217132a0 fffff800`26152256 tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15
0c ffffd000`217132d0 fffff801`d2f1066c nt!KeExpandKernelStackAndCalloutInternal+0xe6
0d ffffd000`217133c0 fffff801`d3ecd97b tcpip!UdpTlProviderSendMessages+0x6c
0e ffffd000`21713440 fffff801`d3ecdbd9 tdx!TdxSendDatagramTransportAddress+0x2eb
0f ffffd000`21713530 fffff801`d3f04516 tdx!TdxTdiDispatchInternalDeviceControl+0x59
10 ffffd000`21713580 fffff801`d3f085bb NEOFLTR_740_30599+0xb516
11 ffffd000`217135f0 fffff801`d3efb739 NEOFLTR_740_30599+0xf5bb
12 ffffd000`21713800 fffff800`264748f2 NEOFLTR_740_30599+0x2739
13 ffffd000`21713880 fffff800`264751c6 nt!IopXxxControlFile+0x8d2
14 ffffd000`21713a20 fffff800`261d77b3 nt!NtDeviceIoControlFile+0x56
15 ffffd000`21713a90 00000000`77402772 nt!KiSystemServiceCopyEnd+0x13
16 00000000`0311ec78 00000000`00000000 0x77402772
Hamdrv.sys is the LogMeIn Hamachi Virtual Miniport driver. It calls into
nt!KeAcquireSpinLockRaiseToDpc which returns the current IRQL at the time the routine is called. This value is passed to
KeReleaseSpinLock when the spin lock is released. Afterwards however, we can see we're waiting (if we look back at the above Processor 0 dump, it appears we never acquired the spinlock, and it spun forever into a loop).
Code:
4: kd> knL
# Child-SP RetAddr Call Site
00 ffffd000`225d4200 fffff800`26144512 nt!KxWaitForLockOwnerShip+0x30
01 ffffd000`225d4230 fffff801`d3eda0a5 nt!IoAcquireCancelSpinLock+0x56
02 ffffd000`225d4260 fffff801`d2f2b55b tdx! ?? ::FNODOBFM::`string'+0x297f
03 ffffd000`225d4310 fffff801`d2f20ca3 tcpip!TcpCleanupTcbWorkQueueRoutine+0x35b
04 ffffd000`225d44a0 fffff801`d2d7f224 tcpip!TcpTcbSendDatagramsComplete+0x2e0
05 ffffd000`225d4510 fffff801`d2f177f7 NETIO!NetioDereferenceNetBufferListChain+0xe4
06 ffffd000`225d45d0 fffff801`d2c6e245 tcpip!FlSendNetBufferListChainComplete+0x57
07 ffffd000`225d4600 fffff801`d2c6ea68 ndis!ndisMSendCompleteNetBufferListsInternal+0x135
08 ffffd000`225d46d0 fffff801`d41c43ce ndis!NdisMSendNetBufferListsComplete+0x2b8
09 ffffd000`225d4840 fffff801`d41c305d Hamdrv+0x33ce
0a ffffd000`225d4880 fffff801`d2cfa628 Hamdrv+0x205d
0b ffffd000`225d48e0 fffff800`2646fd1a ndis!ndisDummyIrpHandler+0x88
0c ffffd000`225d4910 fffff800`261d77b3 nt!NtReadFile+0x7ca
0d ffffd000`225d4a90 00007ffd`bbe5abea nt!KiSystemServiceCopyEnd+0x13
0e 00000000`01d1fb28 00000000`00000000 0x00007ffd`bbe5abea
^^ Same thing here, we can see the LogMeIn Hamachi driver.
nt!IoAcquireCancelSpinLock routine synchronizes cancelable-state transitions for IRPs in a multiprocessor-safe way. We can see afterwards we're waiting for ownership of the lock, but as said above, we never get it due to it spinning endlessly and causing a loop.
------------------
1. Either update/uninstall LogMeIn Hamachi.
2. Uninstall Samsung RAPID Mode Disk Filter ASAP.
3. Uninstall Asus PC Probe, AI Suite, etc. Any/all installed Asus bloatware.
Regards,
Patrick
