Windows · Windows Server  ·  high  ·  Core Windows faults

STOP 0x00000133 — DPC_WATCHDOG_VIOLATION

A driver held the processor at high IRQL for longer than the watchdog allows. Nearly always a storage or firmware issue rather than the driver the crash names.

What you see

Random bugchecks with 0x133, often while the disk is busy — during backups, updates or large copies. Parameter 1 is 0 for a single long DPC and 1 for a run of them.

What is actually wrong

Most often an SSD with outdated firmware, or the generic Microsoft AHCI driver in place of the vendor's. Also seen with old iSCSI initiators and some virtualisation NIC drivers.

Codes and articles

0x000001330x133DPC_WATCHDOG_VIOLATION

Fixes (2)

Update SSD firmware and the storage controller driver
Windows30–60 minutesmedium risknot reversible

There is an SSD present. Firmware updates cannot be undone, so back up first.

  1. Identify the drives and their firmware revisions.

    PowerShell
    Get-PhysicalDisk | Select-Object FriendlyName, Model, FirmwareVersion, MediaType

  2. Back up. Firmware flashing carries a small but real risk of data loss.

  3. Get the vendor's own toolbox (Samsung Magician, Crucial Storage Executive, Intel MAS, WD Dashboard) and apply any firmware update it offers.

  4. Install the chipset and storage controller driver from the motherboard or laptop vendor, not from Windows Update.

    Windows Update supplies a generic driver that works but does not always handle the controller's queueing behaviour, which is what the watchdog is complaining about.

  5. Restart and leave it under normal load for a day.

Confirm it workedNo new 0x133 entries appear in the system log.
PowerShell
Get-WinEvent -FilterHashtable @{LogName='System'; ID=1001} -MaxEvents 10 | Format-List TimeCreated, Message
If you need to undo itFirmware cannot be rolled back. Drivers can, through Device Manager → Properties → Driver → Roll Back Driver.
Find the offending driver in the dump
Elevated PowerShell + WinDbg30 minuteslow riskreversible

No obvious storage candidate, or the firmware update did not help.

  1. Make sure a kernel dump is actually being written.

    PowerShell
    Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' | Select-Object CrashDumpEnabled, DumpFile

  2. Install WinDbg from the Microsoft Store, then open C:\Windows\MEMORY.DMP.

  3. Run the automatic analysis and read MODULE_NAME and IMAGE_NAME.

    Command Prompt
    !analyze -v

    For 0x133 the module blamed is usually accurate, unlike some other bugchecks where ntoskrnl is reported for everything.

  4. Update or remove whatever driver it names.

Confirm it workedThe machine survives the workload that used to crash it.
If you need to undo itReinstall the driver you removed if it turns out to be needed.

Reference

Bug Check 0x133 — Microsoft Learn ↗

Related faults

STOP 0x0000007B — INACCESSIBLE_BOOT_DEVICEWindowsSTOP 0x0000009F — DRIVER_POWER_STATE_FAILUREWindowsSTOP 0x00000139 — KERNEL_SECURITY_CHECK_FAILUREWindowsSTOP 0x0000001E — KMODE_EXCEPTION_NOT_HANDLEDWindowsSTOP 0x00000050 — PAGE_FAULT_IN_NONPAGED_AREAWindows0xC000021A — STATUS_SYSTEM_PROCESS_TERMINATEDWindows

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.