⚠ CrashDecoder

0x00000133 DPC_WATCHDOG_VIOLATION

Windows runs a watchdog that measures how long drivers spend at high priority. When one exceeds its allowance, the watchdog stops the machine deliberately rather than let a driver starve the rest of the system indefinitely. This stop code has an unusually strong association with storage - specifically SSD firmware and a controller driver mismatch that has been producing it for years.

Updated 2026-07-27Stop errorAlso written: 0x133, DPC WATCHDOG VIOLATION, dpc_watchdog_violation

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: DPC_WATCHDOG_VIOLATION

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0x00000133 (0x0000000000000001, 0x0000000000001e00, 0x0000000000000000, 0x0000000000000000).

What the error actually means

When hardware raises an interrupt, the driver handling it is expected to do the minimum possible immediately and defer the rest. That deferred work runs as a Deferred Procedure Call, at DISPATCH_LEVEL - high enough that ordinary thread scheduling is suspended while it executes.

That arrangement only works if DPCs are short. A DPC that runs for a long time blocks every thread on that processor, and the machine becomes unresponsive with no mechanism to intervene.

So Windows watches. If a single DPC runs past its allowance, or if the system spends too much cumulative time at DISPATCH_LEVEL, the watchdog fires and stops the machine. It is a deliberate safety net catching a driver behaving badly - which means, as with IRQL violations, the fault belongs to a specific driver rather than to Windows.

Reading the parameters

Parameter 1 splits this into two genuinely different diagnoses, and the remaining parameters shift meaning with it - so read parameter 1 first and then interpret the rest accordingly.

For scale: Microsoft states that DPCs should not run longer than 100 microseconds and interrupt service routines no longer than 25 microseconds, while the actual timeouts enforced are set much higher. A routine that trips this watchdog is not slightly slow, it is orders of magnitude over.

ParameterWhat it holds
1 = 0x0A single DPC or ISR exceeded its time allotment. Here parameter 2 is the DPC time count in ticks, parameter 3 is the allotment it was permitted, and parameter 4 is the address of the DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK. Microsoft notes the offending component can usually be identified from a stack trace - this is the tractable case.
1 = 0x1The system cumulatively spent too long at DISPATCH_LEVEL or above. Here parameter 2 is the watchdog period, parameter 3 is the address of the DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, and parameter 4 is reserved. This is the harder case: Microsoft notes the code may not stop in the offending area at all, so the stack often does not name the culprit and event tracing is needed instead.
Comparing 2 and 3 when parameter 1 is 0The two values are directly comparable - Microsoft's own example shows a tick count of 501 against an allotment of 500. How far over the limit the routine ran tells you whether it was marginally slow or badly stuck.
The triage blockWhichever parameter holds it, dt nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK <address> displays it. The !dpcs command lists queued DPCs, which is often more immediately useful.

What actually triggers it

This is one of the few stop codes with a genuinely dominant cause rather than a spread.

CauseHow oftenDetail
The wrong SATA controller driverCommonThe best-known cause of this bugcheck. A system running Intel's Rapid Storage driver (iaStorA.sys) with an SSD it does not handle well produces this repeatedly. Switching to Microsoft's standard AHCI driver (storahci.sys) resolves a large share of cases outright.
Outdated SSD firmwareCommonGenuinely fixed by firmware updates, which is unusual - most 'update the firmware' advice is speculative, but here vendors have shipped releases specifically addressing controller stalls that cause this.
Network and Wi-Fi driversOccasionalNetwork stacks do substantial DPC work. An old or mismatched adapter driver overruns its allowance, particularly under sustained load.
USB devices and hubsOccasionalA faulty device, a failing hub or an unpowered hub with too much attached can stall the USB stack long enough to trip the watchdog. Cheap docking stations are a recurring offender.
Chipset and platform driversOccasionalEspecially on a fresh Windows install where Microsoft's generic drivers are still in place instead of the vendor's.
Failing storage hardwareOccasionalA drive that stalls while retrying reads holds up the storage DPC. Distinguishable from a firmware bug by SMART data and by whether the problem follows the drive.

Narrowing it down

Given how concentrated the causes are, checking storage first is a better use of time than a general sweep.

Read parameter 1

Pull it from the bugcheck event in the System log, or from !analyze -v. Then check IMAGE_NAME in the same output - Microsoft's own worked example for the single-DPC case names BthA2DP.sys, a Bluetooth audio driver, which is exactly the kind of peripheral driver that turns up here.

What it tells you

A value of 0 means one specific DPC or ISR overran, and Microsoft notes the offending component can usually be identified from a stack trace - so read IMAGE_NAME and the stack, and you often have your answer.

A value of 1 is the cumulative case and is harder: Microsoft warns the code may not stop in the offending area at all, so the named module can be misleading. It is also the pattern most often seen with the storage causes below.

Identify your storage controller driver

Open Device Manager, expand IDE ATA/ATAPI controllers and read the entry. Alternatively:

Get-PnpDevice -Class SCSIAdapter,HDC -PresentOnly |
  Select-Object FriendlyName, Status |
  Format-Table -AutoSize
What it tells you

If it names an Intel Rapid Storage or vendor-specific controller rather than Standard SATA AHCI Controller, you are in the most common failure case and the driver swap below is the first thing to try.

Check drive health and firmware version

Run CrystalDiskInfo. Note the model, the firmware revision and the health status, then check the manufacturer's support page for a newer firmware release.

What it tells you

An SSD on old firmware with a known fix is the single most likely explanation. Degraded health moves this from a firmware problem to a failing-drive problem.

Disconnect USB peripherals

Unplug everything except keyboard and mouse - especially docks, hubs, external drives and capture devices - and run the machine for a day.

What it tells you

If the crashes stop, reconnect devices one at a time. A failing hub or a device with a bad driver is easy to find this way and impossible to find any other way.

Fixes, cheapest first

The first two resolve most cases. Do them before anything else.

  1. Switch to the standard AHCI driver

    Effort: 15 minutes · Risk: Low on plain AHCI - high on RAID or VMD

    Read this before the steps, not after

    Do not do this if your storage runs in RAID mode or with Intel VMD enabled. Switching the controller driver in either configuration can leave the machine unbootable.

    VMD is the one that catches people out. On 11th-generation and later Intel platforms, particularly OEM laptops, it is frequently enabled by default with a single ordinary NVMe drive and no RAID array anywhere. If you check only for RAID you will conclude this is safe when it is not.

    Check the storage mode in UEFI first. If it says anything other than AHCI, stop here.

    Check BitLocker before changing firmware settings

    If the drive is protected by BitLocker or Windows Device Encryption, changing storage-controller settings triggers a recovery-key prompt on the next boot. Without the 48-digit key, the volume is gone permanently.

    Windows 11 turns Device Encryption on by default on a lot of consumer hardware, so check rather than assume:

    manage-bde -status

    If protection is on, retrieve your recovery key from your Microsoft account first, or suspend protection for a single reboot:

    manage-bde -protectors -disable C: -RebootCount 1

    With both of those checked, this is the classic fix for this bugcheck and it is reversible.

    1. Open Device Manager and expand IDE ATA/ATAPI controllers.
    2. Right-click the SATA AHCI controller entry and choose Update driver.
    3. Choose Browse my computer, then Let me pick from a list of available drivers.
    4. Select Standard SATA AHCI Controller and confirm.
    5. Reboot.
    Watch out

    If the machine will not boot afterwards, boot from Windows installation media, choose Repair your computer, and use System Restore to reverse the driver change.

  2. Update SSD firmware

    Effort: 30 minutes · Risk: Medium

    Get the model and current firmware revision from CrystalDiskInfo, then check the vendor's support page. Samsung Magician, Crucial Storage Executive, WD Dashboard and the equivalents handle this for their own drives.

    Watch out

    Back up before flashing firmware. Interrupting a firmware update can leave the drive unusable, so do it on mains power and do not touch the machine while it runs.

  3. Update chipset and network drivers

    Effort: 30 minutes · Risk: Low

    Install the chipset package from your board or system vendor rather than relying on what Windows Update supplies. Then update the network adapter driver from the adapter vendor.

    On a laptop, the system vendor's driver is usually the right one, since the adapter is often a customised variant.

  4. Isolate USB devices

    Effort: A few days · Risk: None

    Run with only keyboard and mouse connected. If stable, reconnect one device per day. Pay particular attention to unpowered hubs, docking stations and anything drawing significant current.

  5. Find the DPC with Verifier or LatencyMon

    Effort: Several hours · Risk: Medium for Verifier

    LatencyMon is the gentler option: it runs in Windows and reports which driver is responsible for the highest DPC execution times, often identifying the offender without a single crash.

    If that is inconclusive, Driver Verifier with DPC checking enabled will force the issue - enable it for non-Microsoft drivers, use the machine until it bugchecks, then read the dump and run verifier /reset.

    Watch out

    Try LatencyMon first. It costs nothing, runs inside Windows, and does not risk a boot loop - it will often name the offending driver without a single crash.

    Verifier deliberately increases crashes and can cause a boot loop. Run verifier /bootmode resetonbootfail before enabling any checks - it makes Verifier disable itself automatically if the machine fails to start, which removes most of the risk. Your manual exit is Safe Mode followed by verifier /reset. Full settings and the escape route are in the Driver Verifier guide.

When it is the hardware, not Windows

Signals that the drive itself is failing rather than its firmware or driver being wrong:

Because the software fixes here are so effective, exhausting them genuinely narrows things. A machine still producing this bugcheck on current firmware, with the standard AHCI driver, and no USB peripherals attached, has a hardware problem rather than a configuration one.

Frequently asked

Why is this stop code so often about SSDs specifically?

Because storage drivers do a lot of their work in DPCs, and an SSD controller that stalls - whether from a firmware bug, garbage collection, or a driver that mishandles a command - blocks that DPC while it waits. The watchdog measures exactly the thing an unresponsive drive causes. It is less that SSDs are unreliable and more that this particular watchdog is well positioned to notice when one hesitates.

Is switching to the standard AHCI driver a downgrade?

Barely, for most people. Intel RST adds features around RAID and some power management, and its raw performance difference on a single SSD is small enough to be hard to measure in normal use. If the swap stops the crashes, that trade is not close. The one situation where it genuinely matters is a RAID array, where you should not switch at all.

It only happens under heavy load. Does that rule out storage?

No - load is exactly when storage DPCs are busiest and when a marginal drive is most likely to stall. Load correlation narrows things toward whichever subsystem is under load rather than away from storage. If the load is disk-heavy, it points at storage more strongly, not less.

What is the difference between this and IRQL_NOT_LESS_OR_EQUAL?

Both involve drivers misbehaving at raised priority, but they break different rules. 0xA means a driver touched memory it could not fault on at that level - an illegal access. 0x133 means a driver took too long - a timing violation. Different detection, and different fixes: the first is about which memory was touched, the second about how long something ran.