How to Fix DPC Watchdog Violation on Windows 11 (0x133)

Write down the crash time, what the PC was doing, and whether the same trigger repeats. Microsoft's current stop-code guidance shows that Windows 11 24H2 and later may use a black error screen instead of blue; it is still the same type of Windows stop error.

• Photograph any What failed filename shown under the stop code.
• If %SystemRoot%\Minidump contains recent .dmp files, copy them to a private folder before cleanup, restore, or reset. On a standard installation this is normally C:\Windows\Minidump.
• Do not delete or rename a .sys file merely because a dump names it.
• Crash dumps may contain system or memory data. Do not post them publicly; share them only with a trusted support channel.

Shut down and disconnect only nonessential hardware added before the first crash: a dock, capture card, external drive, USB audio device, controller, Bluetooth adapter, or second display. Keep the keyboard, mouse, primary display, and system drive connected.

• If the crash stops, reconnect one item at a time and use the device maker's supported driver or firmware path.
• If you recently enabled CPU, GPU, XMP, or EXPO tuning, return it to the PC or motherboard maker's supported defaults for the comparison test.
• Do not reset the BIOS, flash firmware, or change storage mode just to see what happens.

Open Settings → Windows Update, install supported updates, and restart. In its consumer stop-error checklist, Microsoft also recommends keeping roughly 10% to 15% free on the Windows drive.

• Install the standard Windows updates first. Review optional driver updates only if they match the device branch you are testing.
• If the first crash appeared immediately after an update, do not assume a newer driver is always better; the rollback branch in the next step may be the safer test.
• Standard Windows 10 support ended October 14, 2025. If the PC is still on Windows 10 without an eligible supported servicing path, plan migration rather than expecting every compatibility issue to receive a new fix.

Right-click Start → Device Manager. Open the category connected to the crash: Display adapters, Storage controllers, Network adapters, Sound, video and game controllers, or Universal Serial Bus controllers. In the device's Properties → Driver tab, record its provider, date, and version.

• Use Windows Update for recommended drivers. If it has no suitable update, use the exact PC, motherboard, GPU, dock, or device manufacturer's official support page.
• If crashes began after a specific driver update, select Roll Back Driver when Windows offers it, then restart and retest the same trigger.
• On laptops, prefer the PC maker's tested graphics, chipset, and storage package when it differs from a generic component-driver package.
• Avoid third-party driver-updater tools. Do not update every device at once; you will lose the useful before-and-after comparison.

After a Windows or driver update

Use the matching device's Driver tab to compare the provider, version, and date. If the first crash followed that exact update, use the supported rollback option before installing unrelated drivers or repair tools.

While gaming or using an external monitor

Test one display with no dock, then update or roll back the exact graphics, chipset, or dock package. Intel documents one DPC Watchdog case triggered by connecting an external monitor to a laptop and points first to Windows Update and the matching graphics driver. That is why the trigger matters more than an old assumption that every 0x133 crash is SATA.

After sleep or wake

Temporarily remove nonessential Bluetooth, USB, audio, network, and dock devices. Compare them one at a time. Permanently disabling sleep can hide the trigger without identifying the device whose power-state change is delayed.

During file copies or when an SSD/NVMe disappears

Back up first, then check the exact drive model, same-time storage events, and its maker's diagnostic or support page. Do not start with chkdsk /r, a firmware flash, a generic SATA controller, or a RAID/AHCI mode change.

When one peripheral or dock triggers the crash

Disconnect it, replace its cable if applicable, and install only its supported driver or firmware. Removing unrelated devices makes the comparison less useful.

Open Settings → System → Recovery → Advanced startup → Restart now. In Windows Recovery, choose Troubleshoot → Advanced options → Startup Settings → Restart, then choose Safe Mode. If Windows cannot reach the desktop, use the same Startup Settings path from its recovery screen.

• If Safe Mode is stable, a third-party driver, service, startup component, or optional device becomes more likely.
• Use Safe Mode to roll back the specific recent driver or uninstall the exact recent software change.
• Safe Mode stability narrows the branch; it does not identify the guilty component by itself.

Press Win + R, enter perfmon /rel, and review the day of the crash. Then open eventvwr.msc and check Windows Logs → System around the recorded time.

• Record the event source, ID, time, and full message for repeating device, controller, display, network, or storage errors.
• Kernel-Power Event ID 41 confirms Windows did not shut down cleanly; it does not by itself identify the original cause.
• Compare at least two crashes. The same nearby device event is more useful than a single unrelated warning.

For repeating crashes, install Microsoft's current WinDbg, open a copied dump from %SystemRoot%\Minidump, and enter !analyze -v in the command window. Microsoft's tool reports the bug-check arguments and the stack that was active when Windows stopped.

• Record MODULE_NAME, IMAGE_NAME, FAILURE_BUCKET_ID, Argument 1, and the first clearly named third-party modules in the stack when those fields are present.
• Compare two or more dumps. One repeated third-party module is more persuasive than a different name in every crash.
• If ntoskrnl.exe is named, do not replace or delete it. It is the Windows kernel and is often where the delayed condition becomes visible, not the original faulty device.
• Argument 1 of 0 points to one overlong DPC/ISR; Argument 1 of 1 describes excessive cumulative high-IRQL time. Both still require the stack and trigger to find the responsible component.

If Windows Update also fails, protected Windows files are damaged, or logs point to component corruption, open Terminal (Admin) and use Microsoft's documented order:

1. Run DISM.exe /Online /Cleanup-Image /RestoreHealth.
2. After DISM finishes successfully, run sfc /scannow.
3. Restart and repeat the original safe trigger.

DISM normally uses Windows Update as its repair source. If it reports that source files could not be found, or Windows Update is unavailable, use Microsoft's documented known-good repair-source method; do not paste a random /Source path from another PC.

If storage evidence specifically suggests file-system damage and important files are already safe, start with chkdsk C: /scan. Do not use /f /r /x as a routine first step; those options can force repairs, dismount a volume, and perform a much longer surface scan without proving which driver caused 0x133.

If the crash began after a known update or installation and targeted rollback is unavailable, review Microsoft's Windows recovery options and choose the least destructive match. Confirm that important files and the BitLocker recovery key are safe first.

• System Restore can undo a recent system-level change when a suitable restore point exists.
• A data-preserving in-place reinstall from installation media must be started from inside a running Windows session, with Keep personal files and apps selected. Booting from the media is the clean-install path and can remove files, apps, and settings. Neither path repairs faulty hardware or incompatible firmware.
• Reset or clean installation is a last resort. A crash that continues during Windows setup strongly raises the need for hardware, firmware, or boot-driver diagnosis.