0x133 DPC_WATCHDOG_VIOLATION
What stop code 0x133 DPC_WATCHDOG_VIOLATION means, the difference between Parameter 1 = 0 and 1, and the WinDbg commands that find the driver stuck at DISPATCH_LEVEL.
Short answer: 0x133 means the CPU spent too long at DISPATCH_LEVEL or above. Either a single DPC or interrupt routine ran past its time allotment (Parameter 1 = 0), or the system spent too long in total at that level (Parameter 1 = 1). With 0, the stack at the crash usually shows the offending driver. With 1, the driver on the stack may only be the last one in line.
Parameters
| Parameter 1 | Meaning | Parameters 2 / 3 / 4 |
|---|---|---|
0 | A single DPC or ISR exceeded its time allotment. | DPC time count (ticks) / DPC time allotment (ticks) / cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK |
1 | The system cumulatively spent too long at DISPATCH_LEVEL or above. | Watchdog period / cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK / reserved |
Microsoft's guidance is that a DPC shouldn't run longer than 100 µs and an ISR not longer than 25 µs; the watchdog timeouts themselves are much longer. Source: Microsoft Learn, Bug Check 0x133.
Reading the dump
!analyze -v # Parameter 1, IMAGE_NAME
k # what was running when the watchdog fired
!dpcs # DPCs queued on each processor
!pcr # this processor's PRCB address, then:
dt nt!_KPRCB <Prcb> Dpc* # DPC and watchdog fields
dt nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK <address from the parameters>
lmvm <driver>- Parameter 1 = 0: the driver in
IMAGE_NAMEand at the top of the stack is a strong suspect. Microsoft's example blamesBthA2DP.sys(Bluetooth audio). - Parameter 1 = 1: the watchdog fires on whatever is running when the total runs out, so the stack can be innocent. Look at the other processors (
~<n>sthenk) for one spinning on a lock. If the dump doesn't settle it, a Windows Performance Recorder trace that includes DPC and ISR activity, read in WPA, on a machine that reproduces it shows which driver uses the time.
Typical causes and fixes
- Storage drivers (SATA AHCI controllers, NVMe, RAID) and their firmware. Update the controller driver and the SSD firmware.
- Audio, Bluetooth, network and graphics drivers with slow interrupt handling.
- Spin lock contention: one driver holds a lock while another processor waits at raised IRQL.
- In VMs, CPU starvation on the host can make honest code exceed the watchdog. Check host contention before blaming the guest's drivers.
Rather not read the dump yourself?
Upload it to DumpTriage. It runs the debugger, reads the output and sends back the faulting module, the stack and a plain-language root cause. Cases the automated passes can't settle go to an engineer. Free during the pilot.
Create an account