Fixing DPC_WATCHDOG_VIOLATION on my PC.

Question

Fixing DPC_WATCHDOG_VIOLATION on my PC.

LC 0

For the past week my PC has all of a sudden started experiencing sudden freezes, occasionally resulting in a blue screen with DPC_WATCHDOG_VIOLATION. The posted file was the report generated from the Windows Debugger. I have no clue what is causing these freezes. My chipset drivers and bios were both updated, and the freezing still occurs. Any help would be appreciated.

DUMP.txt

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

3 answers

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Had a look at your dump the crash isn't coming from a third-party driver. The faulting module is ntkrnlmp.exe which is the Windows kernel itself, and the failure bucket is nt!KeAccumulateTicks inside a clock interrupt routine. What's happening is Windows' own memory working set manager ran too long at a high interrupt level and the watchdog timer fired.

The more telling detail is your OS version the dump shows build 19041.1, which is the original Windows 10 20H1 release from mid-2020 with no cumulative updates installed. Microsoft fixed several bugs in this exact area (timer interrupts and working set management) in updates that came out shortly after that build was released. Your chipset and BIOS being updated doesn't help here because the problem is inside Windows itself.

The fix is straightforward run Windows Update and install all available updates. Given how far behind build 19041.1 is, it'll likely be a large download but that should resolve it. Once you're on a current build, if you still get the occasional freeze it would be worth checking your RAM with Windows Memory Diagnostic as well, since working set issues can sometimes be aggravated by unstable memory.

Full breakdown of DPC_WATCHDOG causes and fixes here if useful: https://errorcodereference.com/error-codes/dpc-watchdog-violation/

Answer 2

Ivan B 111.3K Independent Advisor

Hi ,

If it is a laptop or desktop, if possible, could you provide the laptop model or your desktop configuration?

Access the c:\windows\minidump folder, copy the files to your desktop, then upload them to OneDrive or Google Drive and post the link here for analysis.

Thanks

LC 0 Reputation points

2026-04-08T23:39:30.76+00:00

This is a desktop and these are the specs
CPU: AMD Ryzen 9 5900X 12-Core Processor

GPU: NVIDIA GeForce RTX 3080

SSD: Samsung SSD 80 PRO 2TB

Here is the minidump file. https://1drv.ms/u/c/a9d269cfd0d65abb/IQA2457DUeh3So5--aFBNnP6AZZ138s8_0fNmR1LLfSH928?e=Cw6P4g
Ivan B 111.3K Reputation points Independent Advisor

2026-04-08T23:43:54.95+00:00

Hi,

What is the model of your motherboard? Based on what you've described, have you already updated the BIOS and chipset drivers correctly?

Thanks
LC 0 Reputation points

2026-04-08T23:52:58.3166667+00:00

I use an X570 Aorus Elite Wifi Motherboard. The BIOS have been updated.
Ivan B 111.3K Reputation points Independent Advisor

2026-04-08T23:57:04.85+00:00

Hii,

First, do the following: Open the command prompt (administrator) and run the commands: sfc /scannow and dism /online /cleanup-image /restorehealth. Wait for the process to complete and restart your computer.

Then, perform a clean boot and, if you wish, uninstall any applications you don't use.

[https://support.microsoft.com/en-us/topic/how-to-execute-a-simple-boot-start-in-windows-da2f9573-6eec-00ad-2f8a-a97a1807f3dd

Thanks
Ivan B 111.3K Reputation points Independent Advisor

2026-04-10T12:16:56.47+00:00

Hi ,

Did you manage to solve the problem?

Thanks
LC 0 Reputation points

2026-04-11T15:38:09.67+00:00

I'm getting random hard freezes. Not even a blue screen shows up. Running sfc /scannow, dism, and chkdsk did not solve the issue. Running tests on the CPU and GPU didn't reveal anything either. I cannot figure out of this is a hardware or software issue. Preferably, I would not like to nuke the OS and reinstall windows unless there is no other option.
LC 0 Reputation points

2026-04-11T15:41:04.71+00:00

Sometime a blue screen would emerge after a freeze with DPC_WATCHDOG_VIOLATION, but I haven't seen one in the past few incidents.
Ivan B 111.3K Reputation points Independent Advisor

2026-04-11T15:43:49.5066667+00:00

Hi,

Do you have more minidumps? If possible, upload them and take a picture of the blue screen.

It's probably a hardware issue. Did you try any BIOS settings?

Thanks
LC 0 Reputation points

2026-04-11T15:46:30.2166667+00:00

After updating, I reset my BIOS settings to the default configurations. There hasn't been any new minidumps since either. Just hard freezes without a blue screen. One freeze persisted for 40+ minutes before I decided to hard shut down the PC.
Ivan B 111.3K Reputation points Independent Advisor

2026-04-11T15:49:52.2366667+00:00

Hi,

Do you have two memory sticks?

Did you check the temperatures?

Thanks
LC 0 Reputation points

2026-04-11T15:51:05.7633333+00:00

I use four sticks of memory. Temp checks revealed nothing suspicious.
Ivan B 111.3K Reputation points Independent Advisor

2026-04-11T15:55:00.7933333+00:00

Hi,

In that case, try testing with just two memory sticks and alternating between them.

Thank you.
LC 0 Reputation points

2026-04-12T00:03:07.7066667+00:00

I'm curious. Have you analyzed the minidump I posted? I just want to know if it points to anything specific.
Ivan B 111.3K Reputation points Independent Advisor

2026-04-12T09:14:16.6633333+00:00

Hi,

Yes, it reports a kernel failure, so it doesn't point to a specific fault. Therefore, we'll have to check every possible component, especially the hardware.

Thanks
Gary Nebbett 6,476 Reputation points

2026-04-12T12:27:53.1833333+00:00

Hello LC,

The dump shows that your system has 24 logical processors. Sometimes the operating system needs to coordinate changes (such as page table modification) across all of the processors and it uses a mechanism called IPI (Inter-Processor Interrupt) to achieve this.

The stack trace shows that the processor that triggered the crash had initiated the IPI mechanism and was waiting for responses from the other processors, most of which never arrived (3 replies, 20 outstanding).

The minidump just contains information for one processor (the one which initiated the crash). Analysing a large dump type might give a hint about what is causing the processors to lock up.

If all processors lock up then the most recently observed behaviour (no crash since no processor is running and able to detect the locked processors, just everything locked) is the expected result.

Gary
LC 0 Reputation points

2026-04-12T16:18:38.9333333+00:00

Thank you for your information.
In the initial post I linked a text file of an analysis of my large dump using the Windows Debug tool. Could you take a look at that and see if you find anything. If you need, I can post the dump file itself.
Ivan B 111.3K Reputation points Independent Advisor

2026-04-12T16:34:44.34+00:00

Hi,

I just checked the error while trying to generate Memory.dumps and unfortunately it's a kernel error again, so I believe it's a persistent hardware failure.

Are you using the latest Windows updates?

Thanks
LC 0 Reputation points

2026-04-12T16:36:26.81+00:00

My Windows is up to date.
LC 0 Reputation points

2026-04-12T16:42:43.8733333+00:00

I might as well post the original memory dump. This was the last blue screen I encountered following a hard freeze. Everything after has been hard freezes for up to 40 minutes without a blue screen.
[removed to protect privacy]
Ivan B 111.3K Reputation points Independent Advisor

2026-04-12T16:47:02.3666667+00:00

Hi,

In this case, I can't check the memory dump; I can only confirm the kernel failure. Usually, it's a kernel and a driver or a hardware failure causing the problem, so we need to test different components.

Did you do the memory test I mentioned before?

If you don't have experience with hardware, I recommend taking it to a repair shop.

Thanks

Gary Nebbett 6,476

Hello LC,

The first hint that the crash occurred while waiting for IPI was the routine name nt!KeFlushMultipleRangeTb in the crash stack ("Tb" may mean page table translation buffer):

00 nt!KeBugCheckEx
01 nt!KeAccumulateTicks
02 nt!KiUpdateRunTime
03 nt!KiUpdateTime
04 nt!KeClockInterruptNotify
05 nt!HalpTimerClockInterrupt
06 nt!KiCallInterruptServiceRoutine
07 nt!KiInterruptSubDispatchNoLockNoEtw
08 nt!KiInterruptDispatchNoLockNoEtw
09 nt!KeFlushMultipleRangeTb
0a nt!MiAgeWorkingSetTail
0b nt!MiWalkPageTablesRecursively
0c nt!MiWalkPageTablesRecursively

The !ipi debugger command confirms this suspicion; here is a truncated and compressed view of the command output:

IPI State for Processor 0
    As a receiver, unhandled requests are pending from processor(s) 10.
    From processor a, active request of type: flush multiple
        Flush Count b4  Flush List ffffffcb87b4844f  (dp ffffffcb87b4844f lb4)

IPI State for Processor 1
    As a receiver, unhandled requests are pending from processor(s) 10.
   From processor a, active request of type: flush multiple
        Flush Count b4  Flush List ffffffcb87b4844f  (dp ffffffcb87b4844f lb4)

IPI State for Processor 2

IPI State for Processor 3

IPI State for Processor 4
    As a receiver, unhandled requests are pending from processor(s) 10.
    From processor a, active request of type: flush multiple
        Flush Count b4  Flush List ffffffcb87b4844f  (dp ffffffcb87b4844f lb4)

IPI State for Processor 5
    As a receiver, unhandled requests are pending from processor(s) 10.
    From processor a, active request of type: flush multiple
        Flush Count b4  Flush List ffffffcb87b4844f  (dp ffffffcb87b4844f lb4)

IPI State for Processor 6
    As a receiver, unhandled requests are pending from processor(s) 10.
    From processor a, active request of type: flush multiple
        Flush Count b4  Flush List ffffffcb87b4844f  (dp ffffffcb87b4844f lb4)

IPI State for Processor 7
    As a receiver, unhandled requests are pending from processor(s) 10.
   From processor a, active request of type: flush multiple
        Flush Count b4  Flush List ffffffcb87b4844f  (dp ffffffcb87b4844f lb4)

IPI State for Processor 8
    As a receiver, unhandled requests are pending from processor(s) 10.
    From processor a, active request of type: flush multiple
        Flush Count b4  Flush List ffffffcb87b4844f  (dp ffffffcb87b4844f lb4)

IPI State for Processor 9
    As a receiver, unhandled requests are pending from processor(s) 10.
    From processor a, active request of type: flush multiple
        Flush Count b4  Flush List ffffffcb87b4844f  (dp ffffffcb87b4844f lb4)

IPI State for Processor 10
    As a sender, awaiting IPI completion from processor(s) 0, 1, 4, 5, 6, 7, 8, 9, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23.

IPI State for Processor 11

IPI State for Processor 12
    As a receiver, unhandled requests are pending from processor(s) 10.
    From processor a, active request of type: flush multiple
        Flush Count b4  Flush List ffffffcb87b4844f  (dp ffffffcb87b4844f lb4)

Processor 10 (the processor that triggered the crash) is awaiting a reply from most of the other processors (except processors 2, 3 and 11 which have replied).

The debugger command !running -t -i only shows stacks from processors 10 and 11 - processors 2 and 3 have possibly "frozen" after replying (processor 10 has been waiting for replies for 120 seconds before initiating the crash).

The processor register context for the frozen processors in the dump file is zeroed - presumably meaning that the processor context could not be retrieved from the frozen processors.

The obvious path of working step by step back to the cause of the problem ends here. There may well be hints about the cause of the problem in the dump, but it will take an inspired guess to find them.

Gary

LC 0 Reputation points

2026-04-12T17:52:28.7566667+00:00

Thank you. In your recommendation, what steps should I take to diagnose the cause?
Ivan B 111.3K Reputation points Independent Advisor

2026-04-12T18:00:48.27+00:00

Hi,

Do the following and guess that your BIOS has an ECO mode. Activate it in the BIOS and run a 24-hour test. The initial idea was to test the memory, and then I'll move on to the next step.

Activate ECO mode at level 1 and run a test to see if crashes occur.

Thanks
Gary Nebbett 6,476 Reputation points

2026-04-12T18:25:26.1433333+00:00

Hello LC,

If I had any clear advice for next possible steps, I would not hesitate to give it.

My initial instinct is that the problem may be related to power (to the CPU, too high/low) or clock speed: my experience is much more software related rather than with hardware so my instinct should be taken with a large pinch of salt.

Gary
Ivan B 111.3K Reputation points Independent Advisor

2026-04-12T18:38:42.37+00:00

Hi,

I understand. Try testing in eco mode. If it's a power issue, in eco mode the clock speed and core count will be limited. If it remains stable, it could be a power issue or a motherboard/processor failure.

Thanks
LC 0 Reputation points

2026-04-12T19:29:35.3333333+00:00

I ran 1 cycle of Memtest86 and no errors were revealed. Should I continue testing my memory, or should I try something else?
Ivan B 111.3K Reputation points Independent Advisor

2026-04-12T20:08:53.5+00:00

Hi,

Try the ECO mode test in the BIOS and see if the problem persists.

Thanks
MartMcd 2,585 Reputation points Volunteer Moderator

2026-04-12T21:25:42.3+00:00

Moderator note :
we advise against posting the large Dump file here in the community, or in any public space, as it may contain Personal Information, I have removed the link.
The minidump.dmp is safe to share.
Gary Nebbett 6,476 Reputation points

2026-04-13T08:37:09.6833333+00:00
Hello LC,

I think that, at the time each processor "froze", the active thread was the "idle" thread.

At the time of the crash, only two processors appear to be not frozen: the processor executing the crash and processor 11, whose stack looks like this:

# Call Site 00 amdppm!ReadIoMemRaw 01 amdppm!ReadGenAddr 02 amdppm!C2Idle 03 amdppm!AcpiCStateIdleExecute 04 nt!PpmIdleExecuteTransition 05 nt!PoIdle 06 nt!KiIdleLoop

A guess is that the "frozen" processors also entered a lower-powered C-state and could not be woken. The "AI Overview" for the Google search "amdppm!ReadIoMemRaw" includes the text:

Disable Processor C-States in BIOS: As a temporary workaround, disabling power-saving features like C-states in the motherboard BIOS can prevent the power management driver from crashing.

Note: amdppm.sys is for AMD power management, but the errors are frequently caused by how the system interacts with the BIOS, rather than a direct failure of the driver file itself.

If the system freezes are frequent and the BIOS allows some control over C-states then one could see if such changes have any impact on the frequency of the freezes. Such a change would only help to identify the problem since it would also have negative impacts on CPU temperature and power consumption and, therefore, should only be made for a short period of time.

Gary
Ivan B 111.3K Reputation points Independent Advisor

2026-04-13T16:56:02.9566667+00:00

Hi,

Regarding AMDPPM issues, the fault is usually in the motherboard or processor rather than a power supply problem; I've seen similar cases.

If ECO mode is correctly configured, the fault won't occur during the test.

Thanks
Ivan B 111.3K Reputation points Independent Advisor

2026-04-14T11:01:52.4+00:00

Hi,

Were you able to run the test in ECO mode?

Thanks
LC 0 Reputation points

2026-04-14T12:39:50.18+00:00

I did not try ECO mode. However, my PC hasn't randomly froze in the past couple days. I am closely monitoring to see if it acts up again and will get back to you if it does.
Ivan B 111.3K Reputation points Independent Advisor

2026-04-14T12:54:51.8666667+00:00

Hi,

In this case, I believe the problem might be intermittent. Keep analyzing it and keep us informed; perhaps resetting the BIOS might have stabilized it.

Thanks

Answer 3

DPC_WATCHDOG_VIOLATION (bug check 0x133) indicates that the system detected a deferred procedure call (DPC) or interrupt service routine (ISR) running too long, or that the system spent too much time at IRQL DISPATCH_LEVEL or above. In most real-world cases this is caused by faulty or misbehaving drivers, or occasionally faulty hardware.

For a home Windows 10 PC without doing deep driver debugging, use the basic troubleshooting guidance that applies to this stop code:

If a specific driver is named in the blue screen or dump analysis, disable or uninstall that driver and check the device manufacturer’s site for an updated version.
Open Event Viewer → Windows Logs → System and look for critical or error events around the time of the freezes/blue screens to identify which device or driver is involved.
If any new hardware was added recently (storage, USB devices, PCIe cards, etc.), temporarily remove or disconnect it and test. Also confirm that all installed hardware is compatible with the version of Windows in use.
Make sure Windows itself is fully updated, as some DPC_WATCHDOG_VIOLATION issues on earlier Windows versions were fixed by OS updates.
If equipped and willing to go deeper, use WinDbg on the crash dump and run !analyze and stack backtrace commands (such as k) to see which driver code was running when the bug check occurred, then update or remove that driver.

If the issue persists after updating/removing suspect drivers and confirming hardware, follow the general blue screen troubleshooting guidance for further isolation.

References:

Share via

Fixing DPC_WATCHDOG_VIOLATION on my PC.

3 answers

Your answer