DPC Watchdog Violation (0x133) Fix: Find the Driver That Stalls

A DPC watchdog violation (DPC_WATCHDOG_VIOLATION, bug check 0x133) is a timeout, not a memory error. Drivers do urgent work in short routines called deferred procedure calls (DPCs), and while one runs, no program, thread or other DPC can use that processor. Windows keeps a watchdog on them; when a driver holds a processor far too long, Windows stops the PC and saves a memory dump that usually shows which driver was running.

Because it’s a timeout, the usual story is a driver waiting on hardware that answers slowly: an SSD on old firmware, a storage controller driver, a Bluetooth audio device, a dock or a graphics card. The PC often freezes or stutters, sometimes for 10 seconds or more, before the stop screen appears. The stop code and fixes are the same on Windows 11 and Windows 10, whether your stop screen is blue or, on newer Windows 11 versions, black.

The most useful single fact is parameter 1. A value of 0 means one DPC overran its limit, and the dump usually names the driver. A value of 1 means the total time spent at high priority added up, and the driver on screen may not be the one to blame.

What the watchdog measures

Microsoft’s guidance to driver writers is that a DPC shouldn’t run longer than 100 microseconds and an interrupt routine no longer than 25 microseconds. The actual watchdog limits are set much higher, so a 0x133 means a driver ran far beyond anything a well-behaved driver needs. Typically it was spinning while it waited for a device to respond.

To read parameter 1, open the crash’s technical details in Reliability Monitor (Parameter 1) or run !analyze -v in WinDbg (Arg1); the blue screen of death guide covers both methods and the basics of opening a dump.

Common causes, in the order to check them

For headset-specific steps, see our Bluetooth troubleshooting guide.

Crashing at startup, or only after a cold start

If stop code 0x133 hits before the desktop appears, or within a minute of signing in, get a stable session before you update anything.

1. Disconnect what you don’t need: dock, USB hubs, external drives and card readers, then restart. If the PC now stays up, reconnect devices one at a time to find the trigger.
2. Use Safe Mode. Two failed starts in a row bring up the recovery screen. Choose Troubleshoot > Advanced options > Startup Settings > Restart, then press 4. If the PC keeps landing back on that screen, see our automatic repair loop guide.
3. Read the result. Safe Mode leaves out most third-party drivers, typically including Bluetooth audio, DisplayLink and VPN drivers and the full graphics driver, but it still loads the boot drive’s storage driver. Stable in Safe Mode: roll back or uninstall the recently changed driver in Device Manager. Still crashing: suspect the storage driver, the drive or other hardware.

If crashes follow a power-on from Shut down but never a Restart, suspect Fast Startup. With it on, Shut down hibernates the Windows kernel and loaded drivers and resumes them at power-on, so a driver stuck in a bad state can carry over; Restart always does a full start. To test, open Control Panel > Power Options > Choose what the power buttons do, select Change settings that are currently unavailable, clear Turn on fast startup (recommended) and select Save changes. If the option isn’t listed, Fast Startup is already off. If turning it off ends the crashes, update the storage, chipset and dock drivers before you turn it back on.

Storage first: firmware, drivers and drive health

Storage is the classic source of 0x133 because disk requests complete through DPCs, so a drive that stalls makes its driver stall with it. Check before you change anything:

1. Check drive health first. In an administrator PowerShell window, Get-PhysicalDisk shows each drive’s HealthStatus; the drive maker’s utility shows SMART warnings and remaining life. If anything shows a warning, back up before you go further.
2. Look for storage timeouts in Event Viewer. Under Windows Logs > System, select Filter Current Log and enter 129,153 in the event ID box. Event 129, logged under the storage driver’s name (stornvme, storahci or an iaStor driver), means a disk request timed out and Windows reset the device. Event 153 from disk means a request failed and was retried. If either clusters around your crash times, treat storage as the prime suspect, even when the dump names a different driver.
3. See which storage driver is actually loaded. In Device Manager, open the controller under IDE ATA/ATAPI controllers or Storage controllers, go to the Driver tab and select Driver Details. If the file listed matches the one in your dumps, you’ve confirmed the suspect, and the driver date tells you how old it is.
4. Update storage and chipset drivers from the PC maker’s support page for your exact model.
5. Update SSD firmware once you have a current backup, using the drive maker’s utility from its own site, such as Samsung Magician, Crucial Storage Executive or SanDisk Dashboard (which replaced Western Digital Dashboard). On business PCs from Dell, HP, Lenovo and similar makers, the SSD is usually an OEM part that these retail tools may not update; get its firmware from the PC maker’s support page or update tool for your exact model instead. Firmware updates are usually safe but not risk-free, so if the drive already reports warnings, copy your data off first.

The SATA AHCI driver swap, and when not to do it

On older PCs whose SATA controller runs in AHCI mode with an outdated vendor driver (Intel Rapid Storage Technology’s iaStorA.sys is the familiar one), switching to Microsoft’s built-in Standard SATA AHCI Controller driver is a long-standing fix for 0x133, including the familiar iaStorA.sys DPC watchdog violation. In Device Manager, expand IDE ATA/ATAPI controllers, open the SATA AHCI controller, and on the Driver tab choose Update driver > Browse my computer for drivers > Let me pick from a list of available drivers on my computer. Select Standard SATA AHCI Controller and restart.

Don’t do this if the controller appears under Storage controllers as an Intel RST, RAID or VMD controller, which is common on newer laptops with NVMe drives. Changing the boot drive’s controller driver there can leave Windows unable to start with INACCESSIBLE_BOOT_DEVICE. Create a restore point and have your BitLocker recovery key before any storage driver change.

Tracing the driver when parameter 1 is 1

A cumulative timeout means the stack shows whoever was running when the limit ran out, not necessarily the worst offender. Narrow it down:

• Compare dumps. If one third-party driver appears in most of them, start there.
• List queued DPCs. In WinDbg, after !analyze -v, the !dpcs command shows the DPCs waiting on each processor and the functions they belong to.
• Measure it live. Record a trace with Windows Performance Recorder while you reproduce the problem, then open it in Windows Performance Analyzer and look at DPC/ISR duration by module. Microsoft’s NT Debugging blog uses that same view on a kernel trace saved in the crash dump. Utilities such as LatencyMon give a simpler per-driver readout.
• Remove variables. Undock, unpair Bluetooth devices and disconnect external drives, then add them back one at a time.

Firmware, docks and the office angle

BIOS and Thunderbolt or USB4 controller firmware updates often fix devices that stall. Install them only from the PC maker’s support page or update tool for your exact model, keep a laptop on AC power, and don’t restart or shut down while the update runs: an interrupted firmware flash can leave the PC unable to start.

Back up first, and suspend BitLocker before a BIOS update so the next start doesn’t ask for the recovery key, then check that BitLocker shows as on again afterward; see finding your BitLocker recovery key.

In an office with the same dock model on every desk, 0x133 on several PCs in the same week usually traces back to one dock firmware or driver release. Update one machine and its dock, confirm it’s stable for a few days, then roll the same versions out to the rest. If Windows Update keeps reinstalling the bad driver and your PCs are managed in Intune, a driver update policy can pause or decline that driver for the whole group. It requires Intune Plan 1 and a Windows license that includes Windows Autopatch, such as Microsoft 365 Business Premium or Windows Enterprise E3/E5, so check your licensing first.

Fixes to skip

0x133 attracts a lot of bad advice. These either don’t work or create a second problem:

• Treating SFC, DISM or chkdsk as the fix. They repair Windows system files and the file system, not a driver or device that takes too long, so they rarely stop 0x133. They’re harmless on a healthy drive; just don’t stop there. If the drive shows warnings or Event 129 timeouts, copy your files off before running chkdsk /r, which reads the whole disk surface and adds load to a struggling drive.
• Registry tweaks that claim to disable the watchdog. The watchdog isn’t the fault; it’s the alarm. Silencing it, even where possible, leaves a driver freezing the processor with no dump to show which one.
• Driver updater utilities. They often install generic chip-maker drivers that the PC maker hasn’t tested on your model. Use the PC maker’s tool or support page.
• Swapping storage drivers on a RAID, RST or VMD system, covered above: the classic route from 0x133 to a PC that won’t start.
• Firmware updates on a drive with no backup. If the drive is already failing, a firmware flash is the worst moment to find out.
• Reinstalling Windows first. Windows Update and the PC maker’s tools can put the same storage, Bluetooth or dock driver straight back.

When it’s hardware, and when to stop

• The drive reports warnings, or 0x133 keeps coming under disk load after firmware and driver updates: back up now and plan to replace the drive.
• Crashes continue in Safe Mode with nothing attached.
• One particular dock or headset triggers it on several PCs: replace that device.

Stop before changing storage controller drivers or BIOS storage settings if you don’t have a current backup and your BitLocker key. If you’d rather not do the driver and firmware work yourself, this is a typical $59 remote fix as long as the PC stays up long enough to connect; replacing a failing drive, dock or headset is hardware work that can’t be done remotely. See how remote support works.

Common questions

Is DPC_WATCHDOG_VIOLATION caused by the SSD?

Often, but not always. Storage requests complete through DPCs, so outdated SSD firmware, an old storage controller driver or a drive that’s starting to fail can stall long enough to trip the watchdog. Bluetooth audio, dock, network and graphics drivers can do the same. Check which driver the dump names before replacing anything.

Why does my PC freeze before the DPC_WATCHDOG_VIOLATION screen?

Because the stop code is a timeout. While a driver’s DPC runs, that processor can’t run programs or other threads, so the screen, mouse or audio stops responding. Windows waits until the watchdog limit is exceeded and then stops the system to capture a dump. Short freezes without a blue screen can come from the same driver.

Can a docking station cause DPC_WATCHDOG_VIOLATION?

Yes. A dock adds USB, network, audio and display controllers, each with its own drivers and firmware. If crashes happen when you dock, undock or wake the laptop while docked, update the dock’s firmware and the PC’s Thunderbolt or USB4 and DisplayLink drivers, then test for a day without the dock.

Is it safe to switch to the Standard SATA AHCI Controller driver?

Only for a SATA controller running in AHCI mode, listed under IDE ATA/ATAPI controllers. On PCs using Intel RST, RAID or VMD mode, usually listed under Storage controllers, changing the boot drive’s driver can stop Windows from starting with INACCESSIBLE_BOOT_DEVICE. Make a restore point and have your BitLocker key ready either way.

Does DPC watchdog violation mean my RAM or CPU is failing?

Rarely. 0x133 measures how long drivers run, not whether memory or the processor works. Failing RAM tends to show up as MEMORY_MANAGEMENT or a different stop code with each crash. A processor that stops responding shows up as CLOCK_WATCHDOG_TIMEOUT (0x101), which Microsoft describes as a processor that isn’t processing clock interrupts. Treat 0x133 as a driver or device problem first, and test RAM only if those other codes appear alongside it.

Why did DPC_WATCHDOG_VIOLATION start after an update?

A Windows or driver update may have replaced a storage, Bluetooth, graphics or dock driver with a version that misbehaves on your hardware. Check Reliability Monitor for what installed that day, use Roll Back Driver on the affected device, and look for a newer version from the PC maker before letting the update reinstall it.

Is a DPC watchdog violation serious?

It won’t damage the PC by itself, but repeat crashes deserve attention. Each one closes open programs without saving, and when the cause is a drive that has started stalling, the crashes can be an early sign of failure. A single crash right after an update may not come back. If it happens again, work through the checks on this page, starting with drive health and a backup.