DPC_WATCHDOG_VIOLATION 0x00000133 – PC freezes then blue screens

Fix it now

The DPC watchdog fired because a single deferred procedure call or interrupt service routine exceeded its time allotment, or because the system spent a prolonged period at DISPATCH_LEVEL or above. Microsoft’s resolution is to disable the driver named in the bug check message and check with its manufacturer for an update.

!analyze -v
!dpcs
driverquery /v /fo table

1. Read the first parameter from the blue screen. 0 means a single DPC or ISR overran its allotment; 1 means the system cumulatively spent an extended period at IRQL DISPATCH_LEVEL or above.
2. If the message names a driver, disable it to isolate the issue and get an update from the manufacturer. That is Microsoft’s documented first step.
3. If it does not, open the newest file in %SystemRoot%\Minidump in WinDbg and run !analyze -v to see which module the DPC belonged to.
4. Check the System log in Event Viewer for other errors in the same window – Microsoft names that as the second thing to do, and a storage or firmware error there changes the whole picture.
5. Confirm any recently installed hardware is compatible with the Windows version in use.

In practice the drivers with real hardware latency behind them turn up most often: storage controllers, network adapters and anything polling a device in a loop. That is a pattern to test, not the documented cause.

If the machine stays up with the suspect driver replaced, stop here. The next section explains what the watchdog is measuring and how to narrow it without a debugger.

Why it happens

A DPC is work a driver defers out of its interrupt handler so the interrupt can return quickly. DPCs run at DISPATCH_LEVEL, which means the thread scheduler is disabled on that processor for the duration – nothing else on that core runs until the routine finishes. That is fine when it takes microseconds and catastrophic when it takes seconds. The freeze you notice for a second or two before the blue screen is the symptom, not a separate fault.

Microsoft publishes the budgets, and they are small: DPCs should not run longer than 100 microseconds and ISRs should not run longer than 25 microseconds, although the actual timeout values on the system are set much higher. Those figures are the design target rather than the trigger, but they tell you the scale of what a driver is supposed to be doing at this level.

The kernel keeps two accounts and parameter 1 says which one tripped. A parameter 1 of 0 means a single DPC or ISR exceeded its time allotment, with parameter 2 the DPC time count in ticks and parameter 3 the allotment. A parameter 1 of 1 means the system cumulatively spent an extended period at DISPATCH_LEVEL or above, with parameter 2 the watchdog period. In both cases Microsoft says the offending component can usually be identified with a stack trace.

The word ISR matters. Microsoft’s parameter table says “a single DPC or ISR”, which puts interrupt service routines in scope alongside deferred calls. A device whose interrupt handler is waiting on hardware that has stopped answering promptly produces this as readily as a badly written DPC does.

Full reference

Parameter 1, and what the rest mean

The neighbouring bug checks

0x000000C7’s parameter 1 is worth knowing because it distinguishes what was found where it should not have been: 0x0 is a timer object, 0x1 a DPC object, 0x2 a DPC routine, 0x3 a DPC object with the wrong processor number, and 0x4 and 0x5 mean the thread’s APC disable count changed during the DPC or timer DPC routine. All of them point at a driver that freed memory without cancelling what was still registered in it.

Reading it in the debugger

Narrowing it without a debugger

1. Note whether the freeze correlates with disk activity, network activity or neither. That single observation removes most of the candidates.
2. driverquery /v /fo table from an elevated prompt lists every driver with its state and start mode – scan it for anything you do not recognise.
3. Disable one suspect device at a time in Device Manager and use the machine normally between changes. Reversible, and it costs nothing.
4. Check powercfg /a to see which sleep states the machine supports, because a machine on modern standby has a different set of drivers active at idle from one using S3.
5. powercfg /sleepstudy produces a modern standby report covering roughly the last three days. It is only useful on a machine actually using modern standby, which is what powercfg /a tells you.

When the driver is up to date and it still crashes

• Roll the driver back rather than forward. A regression in a current release is at least as likely as a bug in an old one, and rolling back is a test you can undo.
• Check disk health. Storage that answers slowly under load produces this without any SMART warning.
• Confirm recently installed hardware is compatible with the Windows version, which is one of Microsoft’s own troubleshooting steps.
• Remove capture, virtualisation and VPN drivers you are not using. They sit in the path whether or not the product is running.
• Read the System log around each crash. This bug check is often the last event in a sequence that started somewhere more informative.

Every code this article covers

Confirm the fix worked

1. The workload that used to freeze the machine runs to completion with no new dump in %SystemRoot%\Minidump.
2. Device Manager shows the replaced driver at the version you installed.
3. The System log has no new storage or network errors in the tested window.
4. The brief freezes stop as well as the crashes – if they continue, the driver is still overrunning and you have only moved the threshold.

Questions people ask about this