DPC_WATCHDOG_VIOLATION - herhalend probleem na onderhoud

[smiba]

Hopelijk is er iemand die misschien nog een tip heeft, maar ik heb nu al weken last van dat mijn computer gemiddeld 3 keer per week crasht met DPC_WATCHDOG_VIOLATION.

Dit lijkt het meest voor te komen terwijl het systeem redelijk idle is, het komt (zover) niet voor wanneer ik game, render of andere compute workloads aanheb

Het gedrag gaat als volg:

1. Eerst loopt mijn complete beeld vast (audio over usb blijft echter wel doorgaan)
2. Na een paar seconde komt alles weer goed, maar heeft mijn keyboard (Corsair K70) geen input meer. Op dit moment weet ik dat ik vrijwel exact 1 minuut heb voordat mijn PC bluescreened
3. Taakbeheer (indien open) loopt vast, Windows UAC schermpjes lopen ook vast (Run as Admin lukt dus niet meer). Muziek (foobar2000, loopt over USB audio) of zelfs YouTube blijft leuk doorgaan en ik kan zelfs rustig mijn word documenten opslaan terwijl ik me voorbereid op de crash. (Zolang er geen keyboard input nodig is)
4. Na 1 minuut krijg ik mijn bluescreen en herstart de computer zich

Het lijkt er dus op dat er duidelijk iets niet goed gaat met een driver die mogelijk wacht op een bepaalde interrupt?
Ik kan alleen totaal niet vinden waar dit door komt en waar Windows nou eigenlijk op wacht, zelfs in de minidumps kan ik echt niets nuttigs halen.

Nu heb ik inmiddels de Windows Performance Recorder, deze hoopte ik snel te kunnen activeren wanneer het zich voordeed zodat ik ~30 seconde aan data kon verzamelen.
Echter vroeg het vandaag om admin rechten via een UAC schermpje en dat werkt ook niet in de crashende staat.

Inmiddels houd ik de Recorder maar open zodat ik alleen op start hoef te drukken, maar het kan weer even duren tot het zich voordoet

Hoe tackle ik dit het beste? Voor mijn gevoel doet het zich voor sinds ik de fans heb vervangen, hier heb ik de computer voor verplaatst naar mijn tafel maar verder niets raars gedaan. Kan ook puur toeval zijn, de build was ook pas krap 1 maand oud.

Nu heb ik zo heel licht mijn verdenkingen bij de SATA kabels, maar ik had dan ander gedrag verwacht. Zie verder ook niet de ECC errors (in communicatie) oplopen in de S.M.A.R.T. data.

Als er meer info nodig is hoor ik het graag

Specs:
CPU: AMD Ryzen Threadripper 3960X
GPU: Gigabyte Aorus Radeon RX 6800XT Master
RAM: 4x G.Skill Trident Z F4-3200C14D (@ 3200Mhz, 14-14-14-32, Quad-Channel)
Mobo: Gigabyte TRX40 Aorus Pro Wifi (rev. 1.1, FBd BIOS)
PSU: be quiet! Dark Power Pro 12 1200W

NVMe SSD: Samsung 980 Pro 1TB
NVMe SSD: XPG SX8200 Pro 2TB

SATA SSD: Samsung 840 EVO 250GB
SATA SSD: Samsung 840 EVO 250GB
SATA HDD: Seagate ST1000DM003 (1TB)
SATA HDD: HGST HUA722020ALA330 (2TB)
SATA HDD: HGST HUA722020ALA330 (2TB)
SAS: IBM LTO-4 Tape Streamer

PCI-e kaart: Elgato HD60 - Capture Card
PCI-e kaart: LSI SAS 9211-8i

[keur0000]

W10 Logboeken nagelopen? systeem/software enz.

[smiba]

keur0000 schreef op donderdag 4 februari 2021 @ 17:25:
W10 Logboeken nagelopen? systeem/software enz.

Yep, voor de crash niets bijzonders er in. Na de crash het gebruikelijke opstarten en dat de shutdown onverwachts was.

[keur0000]

Deze gevonden:
https://www.windowsphonei...0133-amd-xata-sys.487647/

Problemen met een blauw scherm oplossen

Verder geeft men de volgende zaken:
dxdiag
chkdsk /f /r
sfc /scannow

[smiba]

keur0000 schreef op donderdag 4 februari 2021 @ 17:43:
Deze gevonden:
https://www.windowsphonei...0133-amd-xata-sys.487647/

Met alle respect maar volgens mij is dit een nep website
Timestamps van de reacties zijn allemaal steeds gelijk gepost door het hele thread

Daarnaast zijn de meeste threads die iets meer detail vereisen echt totale onzin. Je ziet dan hoe de posts gewoon gescraped zijn van andere forums in de hoop dat er iets nuttigs uitkomt:
https://www.windowsphonei...sion.508142/#post-2425839

Ik waardeer je input, maar ik ben zelf ook al genoeg google searches verder

keur0000 schreef op donderdag 4 februari 2021 @ 17:43:
dxdiag
chkdsk /f /r
sfc /scannow

Anyways:

[keur0000]

Hmmm vaag, dan is het toch software.... W10 toepassing logboek misschien?

[Douweegbertje]

Ik zou met je memory gaan spelen. 2 slots eruit halen, heb je het nog steeds, dan de andere 2 slots proberen.
Wat ik had was ongeveer hetzelfde. Nergens iets te vinden en nergens iets van logs. Uiteindelijk kwam ik er zo achter dat memory slot 3 bij mij dus brak was.

En misschien is het een long-shot maar het proberen wellicht waard

edit; nu ik zo verder kijk. Heb je hier niet iets aan? https://answers.microsoft...7e-491e-bc42-b223d50fad25

[ Voor 23% gewijzigd door Douweegbertje op 04-02-2021 18:18 ]

[smiba]

Douweegbertje schreef op donderdag 4 februari 2021 @ 18:16:
Ik zou met je memory gaan spelen. 2 slots eruit halen, heb je het nog steeds, dan de andere 2 slots proberen.
Wat ik had was ongeveer hetzelfde. Nergens iets te vinden en nergens iets van logs. Uiteindelijk kwam ik er zo achter dat memory slot 3 bij mij dus brak was.

En misschien is het een long-shot maar het proberen wellicht waard

Zeker een poging waard! Ik bedacht me ook nog dat ik een hele kleine memory timing OC had toegepast, (14-14-14-34 is native). Hier draai ik al weken mee voor dat het probleem zich voordeed, maar ik heb 'm toch maar even teruggedraaid. Mocht dat niet werken ga ik het nog maar eens proberen met iets minder geheugen.
(Al sluit dat niet perse uit dat het slot problematisch is, gezien ook de memory controller's layout compleet veranderd. Dual-channel vs. quad-channel etc.)

Zou misschien wel verklaren waarom het onder load niet/minder lijkt te gebeuren. Op idle haalt geardown waarschijnlijk de timings en clockspeed naar beneden wat misschien net een stapje te veel is. (Geen idee of geardown daadwerkelijk werkt in XMP mode?)

Douweegbertje schreef op donderdag 4 februari 2021 @ 18:16:
edit; nu ik zo verder kijk. Heb je hier niet iets aan? https://answers.microsoft...7e-491e-bc42-b223d50fad25

Driver is niet aanwezig, is volgens mij van Intel Rapid Storage. Heb geen intel chipset (amd build) dus ook niet aanwezig. Toch voor de zekerheid even gekeken maar ik gebruik gewoon storahci.sys

[Thralas]

smiba schreef op donderdag 4 februari 2021 @ 17:22:
Het lijkt er dus op dat er duidelijk iets niet goed gaat met een driver die mogelijk wacht op een bepaalde interrupt?

Ongeveer.

quote: https://docs.microsoft.co...33-dpc-watchdog-violation

The DPC_WATCHDOG_VIOLATION bug check has a value of 0x00000133. This bug check indicates that the DPC watchdog executed (..) because the system spent a prolonged time at an interrupt request level (IRQL) of DISPATCH_LEVEL or above.

Ik kan alleen totaal niet vinden waar dit door komt en waar Windows nou eigenlijk op wacht, zelfs in de minidumps kan ik echt niets nuttigs halen.

Het 'wacht' niet, er is een watchdog die je systeem afschiet omdat het systeem teveel tijd kwijt is aan interruptroutines door een driver die zich misdraagt.

Parameter 1:

The system cumulatively spent an extended period of time at IRQL DISPATCH_LEVEL or above. The offending component can usually be identified with a stack trace.

Je zegt naar de minidumps te hebben gekeken, hoe ziet !analyze -v eruit? Welke drivers staan er in de stack trace? Dat is niet heilig (zie MSDN), maar een goed beginpunt.

For parameter of 1, the code may not stop in the offending area of code. In this case one approach is to use the event tracing to attempt to track down which driver is exceeding it's normal execution duration.

Met Windows Event Tracing kun je het vast oplossen, maar wellicht is Latencymon een iets toegankelijkere optie. Het tabblad drivers laat zien hoeveel tijd iedere driver in ISRs/DPCs spendeert.

Geheugen verwijderen of disks checken kun je net zo goed achterwege laten, dat is nergens op gebaseerd en gaat hier niet helpen.

[ Voor 4% gewijzigd door Thralas op 05-02-2021 13:28 ]

[smiba]

Thralas schreef op vrijdag 5 februari 2021 @ 13:25:
Het 'wacht' niet, er is een watchdog die je systeem afschiet omdat het systeem teveel tijd kwijt is aan interruptroutines door een driver die zich misdraagt.

Thanks voor de uitleg, ik leer graag hoe exacte processen en low-level functies binnen mijn systeem verlopen! (Mocht je trouwens resources hebben om meer te leren over dit type interrupt, voel je vrij om ze te linken)

Thralas schreef op vrijdag 5 februari 2021 @ 13:25:
Je zegt naar de minidumps te hebben gekeken, hoe ziet !analyze -v eruit? Welke drivers staan er in de stack trace? Dat is niet heilig (zie MSDN), maar een goed beginpunt.

Nu moet ik je heel eerlijk zeggen dat ik er niet via windbg heb ingekeken, dit in het verleden wel eens geprobeerd te gebruiken bij applicatie crashes (in het specifiek memory leaks) maar het was nooit echt duidelijk.

Nog maar eens geprobeerd en ik denk dat het deze keer me een stuk verder brengt! Laat duidelijk zien dat het in de usb driver zit en waarschijnlijk door de HTC Vive Pro driver komt. Dit lijkt te matchen met wanneer de symptomen verschenen, ik had namelijk mijn fans 2 dagen voor mijn HTC Vive VR Headset binnen kwam vervangen!

Inmiddels teruggestuurd (toch gegaan voor valve index, offtopic) dus ik heb de Vive drivers verwijderd van mijn systeem. Eens kijken of dat het probleem oplost!

code:

25: kd> .symfix; .reload
Loading Kernel Symbols
..

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

.............................................................
................................................................
................................................................
..................................................
Loading User Symbols
Loading unloaded module list
........................................
25: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
    DISPATCH_LEVEL or above. The offending component can usually be
    identified with a stack trace.
Arg2: 0000000000001e00, The watchdog period.
Arg3: fffff803636fa320
Arg4: 0000000000000000

Debugging Details:
------------------

*************************************************************************
***                                                                   ***
***                                                                   ***
***    Either you specified an unqualified symbol, or your debugger   ***
***    doesn't have full symbol information.  Unqualified symbol      ***
***    resolution is turned off by default. Please either specify a   ***
***    fully qualified symbol module!symbolname, or enable resolution ***
***    of unqualified symbols by typing ".symopt- 100". Note that   ***
***    enabling unqualified symbol resolution with network symbol     ***
***    server shares in the symbol path may cause the debugger to     ***
***    appear to hang for long periods of time when an incorrect      ***
***    symbol name is typed or the network symbol server is down.     ***
***                                                                   ***
***    For some commands to work properly, your symbol path           ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: TickPeriods                                   ***
***                                                                   ***
*************************************************************************

DUMP_FILE_ATTRIBUTES: 0xc
  Insufficient Dumpfile Size
  Kernel Generated Triage Dump

DPC_TIMEOUT_TYPE:  DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x133

PROCESS_NAME:  ViveProSetting

CURRENT_IRQL:  d

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

IRP_ADDRESS: ffffffffffffff88

LAST_CONTROL_TRANSFER:  from fffff80362e3aa0c to fffff80362df5780

STACK_TEXT:  
ffff8a81`35ea3e18 fffff803`62e3aa0c : 00000000`00000133 00000000`00000001 00000000`00001e00 fffff803`636fa320 : nt!KeBugCheckEx
ffff8a81`35ea3e20 fffff803`62c6f9a3 : 00003804`2ffeb940 ffff8a81`35e89180 00000000`00000000 ffff8a81`35e89180 : nt!KeAccumulateTicks+0x1c880c
ffff8a81`35ea3e80 fffff803`62c6f48a : ffffd408`9b022d80 fffff105`fd76abc0 00000000`00000000 ffffd408`b4312080 : nt!KeClockInterruptNotify+0x453
ffff8a81`35ea3f30 fffff803`62d27ef5 : ffffd408`9b022d80 00000000`00000000 00000000`00000000 ffffd596`b456b168 : nt!HalpTimerClockIpiRoutine+0x1a
ffff8a81`35ea3f60 fffff803`62df722a : fffff105`fd76abc0 ffffd408`9b022d80 00000000`00000001 00000000`00000000 : nt!KiCallInterruptServiceRoutine+0xa5
ffff8a81`35ea3fb0 fffff803`62df7797 : fffff105`fd76b160 ffff7ac2`3ebbb8d8 ffffd408`b100d240 00000000`00000000 : nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
fffff105`fd76ab40 fffff803`62c43962 : fffff105`fd76ad00 fffff803`ac05f276 00000000`00000015 ffffd408`ae23f990 : nt!KiInterruptDispatchNoLockNoEtw+0x37
fffff105`fd76acd0 fffff803`62c4a29f : fffff105`fd76b160 fffffff6`00000080 00000000`00000000 00000000`0000023a : nt!KiAcquireKobjectLockSafe+0x32
fffff105`fd76ad00 fffff803`62c49d59 : 00000000`00000000 fffff105`fd76aed0 00000000`00000000 00000000`00000000 : nt!KeSetEvent+0x6f
fffff105`fd76ad90 fffff803`62c67ce0 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd408`b908ea60 : nt!IopCompleteRequest+0x599
fffff105`fd76ae50 fffff803`62df9ae0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDeliverApc+0x1b0
fffff105`fd76af00 fffff803`62c4c84b : 00000000`00000000 ffffd408`b908ea60 00000000`00000000 fffff803`ad269000 : nt!KiApcInterrupt+0x2f0
fffff105`fd76b090 fffff803`633b1019 : fffff105`fd760061 fffff105`fd76b1c8 00000000`00000004 01000000`00100000 : nt!ExFreeHeapPool+0xbb
fffff105`fd76b170 fffff803`ad26207d : 00000000`c00000b5 fffff803`ad267130 00000000`00000000 ffffd408`c68cad20 : nt!ExFreePool+0x9
fffff105`fd76b1a0 fffff803`ad26c253 : 00000000`00000003 ffff8a81`3b3b8ed0 00000000`00000100 fffff803`00000000 : hidusb!HumGetDescriptorRequest+0x25d
fffff105`fd76b210 fffff803`ad261507 : 00000000`00000000 ffffd408`a0c93580 ffffd408`ccb5d010 00000000`00000000 : hidusb!HumGetStringDescriptor+0xe3
fffff105`fd76b290 fffff803`b1773989 : fffffbc5`409d9dc0 00000000`00000004 ffffd408`ccb5d010 00000000`00000001 : hidusb!HumInternalIoctl+0x3e7
fffff105`fd76b580 fffff803`b1785470 : 00000000`00000010 ffffd408`ccb5d5a8 ffffd408`ccb5d010 00000000`000b01c2 : HIDCLASS!HidpCallDriver+0xb9
fffff105`fd76b5f0 fffff803`b178820b : ffffd408`ccb5d010 fffff105`00000000 00000000`00000010 ffffd408`b40885e0 : HIDCLASS!HidpCallDriverAsynchronous+0x2c
fffff105`fd76b620 fffff803`b177730a : ffffd408`ccb5d5a8 ffffd408`b40995e0 ffffd408`b40885e0 00000000`00000000 : HIDCLASS!HidpGetDeviceString+0xd7
fffff105`fd76b670 fffff803`b1772661 : ffffd408`b40995c0 ffffd408`ccb5d010 ffffd408`c1e0f700 fffff803`62ca6b01 : HIDCLASS!HidpIrpMajorDeviceControl+0xc8a
fffff105`fd76b770 fffff803`62c52f55 : 00000000`00000002 ffffd408`ccb5d010 00000000`00000001 ffffd408`b4312080 : HIDCLASS!HidpMajorHandler+0x191
fffff105`fd76b800 fffff803`62ffd518 : fffff105`fd76bb80 ffffd408`ccb5d010 00000000`00000001 00000000`002533b5 : nt!IofCallDriver+0x55
fffff105`fd76b840 fffff803`62ffcde5 : 00000000`000b01c2 ffffd408`ccb5d5f0 00000000`00000000 fffff105`fd76bb80 : nt!IopSynchronousServiceTail+0x1a8
fffff105`fd76b8e0 fffff803`62ffc7e6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x5e5
fffff105`fd76ba20 fffff803`62e071b8 : fffff105`fd76bb18 000000a3`a7d2ed50 000000a3`a7d2ed44 000000a3`00000004 : nt!NtDeviceIoControlFile+0x56
fffff105`fd76ba90 00007fff`8652c094 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
000000a3`a7d2ec38 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007fff`8652c094


STACK_COMMAND:  kb

FOLLOWUP_IP: 
hidusb!HumGetDescriptorRequest+25d
fffff803`ad26207d e9ca000000      jmp     hidusb!HumGetDescriptorRequest+0x32c (fffff803`ad26214c)

SYMBOL_STACK_INDEX:  e

SYMBOL_NAME:  hidusb!HumGetDescriptorRequest+25d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: hidusb

IMAGE_NAME:  hidusb.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  0

IMAGE_VERSION:  10.0.19041.1030

BUCKET_ID_FUNC_OFFSET:  25d

FAILURE_BUCKET_ID:  0x133_ISR_hidusb!HumGetDescriptorRequest

BUCKET_ID:  0x133_ISR_hidusb!HumGetDescriptorRequest

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x133_isr_hidusb!humgetdescriptorrequest

FAILURE_ID_HASH:  {c13f5902-b00b-40e7-ef23-edbfd49d76bc}

Followup: MachineOwner
---------

Thralas schreef op vrijdag 5 februari 2021 @ 13:25:
Met Windows Event Tracing kun je het vast oplossen, maar wellicht is Latencymon een iets toegankelijkere optie. Het tabblad drivers laat zien hoeveel tijd iedere driver in ISRs/DPCs spendeert.

Latencymon ben ik bekend mee!
Toen ik net mijn build voltooid had, had ik last van stuttering en dat kwam door een slechte SATA kabel. Was vrij duidelijk te zien dat hij erg lange interupts kreeg vanuit de sata controller.

Dit WATCHDOG_VIOLATION probleem is er echter niet in zichtbaar, volgens mij gedraagt de driver zich gewoon normaal... tot ie dat ineens niet meer doet.

Thralas schreef op vrijdag 5 februari 2021 @ 13:25:
Geheugen verwijderen of disks checken kun je net zo goed achterwege laten, dat is nergens op gebaseerd en gaat hier niet helpen.

Ik wou ook niet te ondankbaar over komen, maar ik vond zelf ook al dat ik die stage voorbij was haha. Heb daarnaast ook liever dat ik echt analytisch een probleem vaststel ipv. op geluk dingen aanpassen.

Anyways vet bedankt, ik hoop dat dit het fixed

EDIT:

Als ik een andere minidump bekijk van dagen eerder komt ook de ViveProSetting naar boven, dus ik denk dat dit het wel moet zijn dan

code:

CURRENT_IRQL:  2

FAULTING_IP: 
nt!KiTryUnwaitThread+50
fffff805`7ee4c3a0 f0480fba6b4000  lock bts qword ptr [rbx+40h],0

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  AV

PROCESS_NAME:  ViveProSetting

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

IRP_ADDRESS: ffffd58ba89f2f88

[ Voor 4% gewijzigd door smiba op 05-02-2021 13:56 ]

[Thralas]

smiba schreef op vrijdag 5 februari 2021 @ 13:49:
Nog maar eens geprobeerd en ik denk dat het deze keer me een stuk verder brengt! Laat duidelijk zien dat het in de usb driver zit en waarschijnlijk door de HTC Vive Pro driver komt. Dit lijkt te matchen met wanneer de symptomen verschenen, ik had namelijk mijn fans 2 dagen voor mijn HTC Vive VR Headset binnen kwam vervangen!

Dat is inderdaad een goede aanwijzing.

Dit WATCHDOG_VIOLATION probleem is er echter niet in zichtbaar, volgens mij gedraagt de driver zich gewoon normaal... tot ie dat ineens niet meer doet.

Ja dat zou zomaar kunnen. Mocht het nog eens gebeuren dan kun je de Windows event tracing tools gebruiken: How can I find out what is causing interrupts on Windows? - die noemde je zelf ook al zag ik, maar dat laat zien hoe je alleen interrupt statistics tracet.

De commandline options van xtrace zou ik dan wel even opzoeken, want je kunt een circulaire tracefile laten schrijven - dan kun je hem gewoon stoppen wanneer het optreedt en weet je zeker dat je niets mist (mogelijk ben je anders weer te laat).

Als ik een andere minidump bekijk van dagen eerder komt ook de ViveProSetting naar boven, dus ik denk dat dit het wel moet zijn dan

Ja, al heb je natuurlijk geen garanties omdat de BSOD (hier) triggert op cumulatieve tijd gespendeerd in ISRs - de spreekwoordelijke druppel die de emmer doet overlopen. Als het iedere keer dezelfde driver/backtrace is dan suggereert dat natuurlijk wel dat deze een redelijk aandeel zou kunnen hebben in het vullen van de emmer. Vooralsnog geen verkeerde aanname.

Hier lijkt het ook nog voort te komen uit een applicatie die een HID device enumereert. Het feit dat een applicatie de kernel omlegt voelt niet helemaal juist, maar het zou zomaar eens kunnen dat die applicatie om de een-of-andere reden in een oneindige lus is beland en het daarmee veroorzaakt.

Anyhow, goede kans dat nu al verholpen is: zo niet biedt een event trace vast meer aanwijzingen.

[smiba]

Problemen hebben zich niet meer voorgedaan, super bedankt nog @Thralas