DPC_WATCHDOG_VIOLATION Blue Screen 0x133: What Microsoft Says

DPC_WATCHDOG_VIOLATION is Windows stop code 0x00000133 (0x133). Microsoft's reference says it means the DPC watchdog fired, "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." Put simply, a piece of low-level code, in general a driver, held the processor for too long. Microsoft's own summary of the usual cause is "faulty driver code that under certain conditions, does not complete its work within the allotted time frame." Its advice for people without a debugger is three concrete checks plus a pointer to its general blue screen guide.

This page is built from the Microsoft Learn article "Bug Check 0x133: DPC_WATCHDOG_VIOLATION" and Microsoft's general page on analysing blue screen data, both read on 12 October 2026 and checked against the Microsoft Docs source files. Microsoft marks the 0x133 page as written for programmers and directs customers to https://www.windows.com/stopcode. Anything we take from the general page rather than the 0x133 page is labelled as such.

What is a DPC, and what is the watchdog timing?

A deferred procedure call is a unit of kernel work that drivers queue to run at a raised priority level, DISPATCH_LEVEL. The 0x133 page does not explain DPCs in depth; it refers readers to Microsoft's "Introduction to DPC Objects" and to the book Windows Internals. What the page does make clear is that both DPCs and interrupt service routines (ISRs) are expected to be short, and that the watchdog exists to catch the ones that are not.

Microsoft gives the target numbers: "DPCs should not run longer than 100 microseconds and ISRs should not run longer than 25 microseconds." It then adds an important qualifier: "the actual timeout values on the system are set much higher." So a 0x133 does not mean a driver ran for 101 microseconds. It means it ran far past the guideline, long enough to trip a much larger safety limit.

What do the parameters say?

Parameter 1 tells you which of the two limits was broken. The meaning of the other three depends on it.

Parameter 1	What happened (Microsoft Learn)	Parameters 2 to 4
0	A single DPC or ISR exceeded its time allotment	2: DPC time count in ticks; 3: DPC time allotment in ticks; 4: triage block address
1	The system spent an extended period, in total, at DISPATCH_LEVEL or above	2: the watchdog period; 3: triage block address; 4: reserved

For both values Microsoft adds that "the offending component can usually be identified with a stack trace." There is a practical difference, though. With parameter 1 = 0, Microsoft's example shows a tick count of 501 against an allotment of 500, and the debugger names the image that was running, in that example BthA2DP.sys. With parameter 1 = 1, Microsoft warns that "the code may not stop in the offending area of code," because the time was used up across many short runs rather than one long one. In that case it suggests event tracing to find which driver is exceeding its normal run time.

You can read the parameters without a debugger. Microsoft's general guide says the bug check event in the Windows system log, viewed in Event Viewer, lists all four.

What Microsoft tells non-programmers to do

The 0x133 page says that if you are not equipped to use the Windows debugger, "you should use some basic troubleshooting techniques." Here they are, in Microsoft's order:

• A driver named in the bug check message. If the blue screen identifies a driver, disable it to isolate the issue, and check with the manufacturer for driver updates.
• The System Log in Event Viewer. Look for additional error messages that might help identify the device or driver causing bug check 0x133.
• Hardware compatibility. Confirm that any newly installed hardware is compatible with your installed version of Windows. Microsoft's example link is the Windows 10 specifications page.
• General troubleshooting. For more, Microsoft refers you to its page "Analyze Bug Check Blue Screen Data."

That is the whole list on the 0x133 page. There is no step about memory tests, disk checks or system file repair for this code, and we are not adding any under Microsoft's name.

What the general guide adds (not the 0x133 page)

Because the 0x133 page sends you to Microsoft's general guide, here is what that guide says that applies. These lines come from "Analyze bug check (stop code error) data," not from the 0x133 page itself.

• Drivers are the usual suspect overall. Microsoft writes that "it's estimated that about three quarters of stop code errors are caused by faulting drivers." That is an estimate across all stop codes, not a figure for 0x133.
• Driver Verifier. A tool built into Windows that examines driver behaviour in real time and raises an exception when it catches an error, so the faulty part of the driver can be examined. Start it by entering Verifier at a command prompt, choose which drivers to check, and keep the list as short as possible because verification adds overhead.
• Isolate and remove. When a bug check is not caused by your own code, the guide says the goal is to work around it: isolate and remove the hardware or software component at fault if possible.
• Record the exact steps. For a recurring problem, the guide says it helps to capture the exact text of the bug check information and the exact actions that lead to the failure.

Checklist before changing drivers

• Photo of the blue screen, including any driver name it shows
• Parameter 1 from the System Log: 0 (one long DPC) or 1 (total time too long)
• Drivers installed or updated just before the first crash
• New hardware added recently, and whether it supports your Windows version
• What you were doing at the time: copying files, using Bluetooth audio, gaming, waking from sleep
• A restore point or backup before disabling or replacing a driver

The activity line is our suggestion for record-keeping, not a Microsoft step. It costs nothing, and it gives whoever reads the logs later a time and a context to match against the System Log entries.

For developers

Microsoft states that determining the cause "requires the Windows debugger, programming experience and access to the source code for the faulting module." Its two worked examples use:

• !analyze -v for the summary and the image name
• k (display stack backtrace) to see what was running, and u, ub, uu to examine the code
• !pcr to show the Processor Control Region, which contains the Prcb address
• `dt nt!_KPRCB Dpc*` to show DPC fields
• `dt nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK
  ` on the parameter 3 or 4 address
• !dpcs to list queued DPCs, for the parameter 1 = 1 case

A fix that is sure to work. Microsoft lists its checks without success rates.

Sources and how to check

• Bug Check 0x133: DPC_WATCHDOG_VIOLATION, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x133-dpc-watchdog-violation
• Analyze bug check (stop code error) data, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/blue-screen-data
• Bug check code reference, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-code-reference2
• Troubleshoot blue screen errors (for regular users): https://www.windows.com/stopcode
• Source: Microsoft Learn, as of 12 October 2026. Checked against the Microsoft Docs source files (MicrosoftDocs/windows-driver-docs). Microsoft documentation is licensed under Creative Commons Attribution 4.0 (CC BY 4.0); this article adapts and summarises it with credit to Microsoft and links to the originals. Microsoft does not endorse this site.