⚠ CrashDecoder

0x00000101 CLOCK_WATCHDOG_TIMEOUT

Windows expects every processor to acknowledge a regular clock interrupt. When one of them stops answering within the allowed window, the system stops - because a core that has gone quiet is either deadlocked or has stopped executing properly, and neither is survivable. Microsoft's description is that the processor is nonresponsive or deadlocked, and in practice the cause is usually voltage rather than software.

Updated 2026-07-28Stop error - processor levelAlso written: 0x101, CLOCK WATCHDOG TIMEOUT, clock_watchdog_timeout

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: CLOCK_WATCHDOG_TIMEOUT

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: 0x00000101 (0x0000000000000018, 0x0000000000000000, 0xfffff8036c1a5180, 0x0000000000000006).

What the error actually means

On a multi-processor system - which today means essentially every system, since every core counts - Windows relies on each processor servicing a periodic clock interrupt. That interrupt is how the scheduler keeps time and how the kernel knows each core is still alive and executing.

If a secondary processor fails to take that interrupt within the allotted interval, Windows has a core that is not responding. It cannot schedule work on it, cannot recover it, and cannot safely continue with part of the machine unaccounted for. So it stops and records which processor went quiet.

The distinction that matters: a core stops answering either because software has deadlocked it - something is holding a lock at high priority and never releasing - or because the silicon itself has stopped executing correctly. The second is far more common on consumer machines, and it usually traces back to voltage.

Reading the parameters

Short and genuinely useful. Parameter 4 in particular is worth noting across several crashes.

ParameterWhat it holds
1The clock interrupt time-out interval, in nominal clock ticks. How long Windows waited before giving up.
2Zero.
3The address of the processor control block (PRCB) for the unresponsive processor. Feed this to the !prcb debugger command to see what that core was doing.
4The index of the hung processor. The most practically useful value here - it identifies which core stopped answering, and whether it is the same one every time.

What actually triggers it

Processor-centric. Drivers can produce it through deadlock, but they are not where the odds sit.

CauseHow oftenDetail
Unstable overclock, undervolt or curve optimiserCommonThe leading cause on any machine that has been tuned at all. A core that has insufficient voltage for its requested frequency simply stops executing correctly. Ryzen curve optimiser offsets and Intel undervolts are frequent sources, and both are notorious for passing hours of stress testing while failing at light, bursty desktop loads.
Unstable memory profileCommonXMP and EXPO push the memory controller, which lives on the processor. A profile beyond what your specific controller sustains manifests as core-level instability rather than as an obvious memory error.
Power deliveryOccasionalA failing or overloaded supply, or motherboard VRMs that cannot hold voltage under transient load. Produces exactly this when a core briefly loses adequate voltage.
Thermal problemsOccasionalA cooler that has come loose or dried thermal paste. Less often the cause than people assume, since modern processors throttle rather than hang - but a badly mounted cooler can create a hotspot that throttling does not save.
Firmware and microcodeOccasionalVendors ship microcode updates through UEFI that address instability on specific processor steppings. Worth checking the changelog before concluding a part is defective.
A driver deadlockOccasionalSoftware holding a spinlock at high IRQL and never releasing it will hang a core. Real, but less common than the electrical causes above - and identifiable from the dump.
A failing processorRareWhere you land when everything is stock, temperatures are fine and the power supply is good. Genuinely rare, but this is one of the few stop codes where it is a serious candidate.

Narrowing it down

Start by removing every tuning variable, because that is where the odds are - and it costs nothing.

Return everything to stock

In UEFI, load optimised defaults, then verify individually: XMP and EXPO off, no CPU multiplier or voltage offset, Precision Boost Overdrive and curve optimiser disabled, no undervolt. Check Windows too - vendor utilities can apply an undervolt at startup independently of firmware.

What it tells you

If the crashes stop, the silicon was fine and the settings were not achievable on your particular sample. This resolves a large share of cases and should be done before anything else is suspected.

Note which core hangs

Record parameter 4 from several crashes. It is the index of the processor that stopped responding.

What it tells you

The same core index every time suggests a specific weak core - relevant on processors where per-core tuning is possible, and meaningful evidence if the part is under warranty. A different core each time points more toward a system-wide cause: power delivery, memory, or a driver deadlock.

Check whether it correlates with load

Note whether crashes happen under sustained load, at idle, or on light bursty work like browsing.

What it tells you

Crashes under heavy load point at thermals or power delivery. Crashes at idle or under light load are the classic signature of an undervolt or curve optimiser offset that is too aggressive - at low load the processor boosts to high clocks at low voltage, which is exactly where an insufficient offset fails.

Look for a driver deadlock in the dump

If stock settings do not help, the dump is worth reading. Microsoft names the relevant commands: !analyze -v first, then !prcb with the address from parameter 3, plus !irql and the stack backtrace commands.

What it tells you

A third-party driver holding a lock at high IRQL identifies a software cause. Nothing but kernel code on the stack leaves the electrical explanations standing.

Fixes, cheapest first

The first fix resolves most cases. The rest are for when it does not.

  1. Remove all overclocking and undervolting

    Effort: 10 minutes · Risk: Low

    Load optimised defaults in UEFI, then confirm each item separately - defaults do not always clear everything, and vendor software can reapply settings after boot.

    1. Disable XMP, EXPO and any manual memory timings.
    2. Clear any CPU multiplier, voltage offset or adaptive voltage setting.
    3. Disable Precision Boost Overdrive and any curve optimiser offsets.
    4. Uninstall or disable vendor tuning software - Ryzen Master, Intel XTU, ThrottleStop, laptop vendor power utilities.
    5. Run at stock for several days before drawing conclusions.
    Watch out

    If stability returns, reintroduce settings one at a time. An offset that was stable two years ago may not be now - silicon ages, and the voltage a core needs for a given frequency drifts upward over time.

  2. Update firmware and chipset drivers

    Effort: 45 minutes · Risk: Medium

    Microcode updates delivered through UEFI have genuinely fixed core instability on particular processor steppings. Check your board vendor's changelog for anything mentioning stability, microcode or AGESA.

    Install the chipset package from the board vendor afterwards, since power management behaviour depends on it.

    Watch out

    If the drive is protected by BitLocker or Device Encryption, a firmware update can change TPM measurements and trigger a recovery-key prompt on the next boot. Check with manage-bde -status and save your key from account.microsoft.com/devices/recoverykey first - Windows 11 enables Device Encryption by default on much consumer hardware.

    Run the update on mains power and do not interrupt it.

  3. Check cooling and temperatures

    Effort: 1-2 hours · Risk: Low

    Log CPU package and per-core temperatures under sustained load with HWiNFO64. Clear dust, confirm every fan spins, and check the case actually exhausts air rather than only drawing it in.

    If temperatures climb unusually fast under load, or the machine is a few years old, reseating the cooler with fresh paste is cheap and often effective.

  4. Test memory at stock

    Effort: Overnight · Risk: None

    With profiles disabled, run MemTest86 from USB for at least four passes. The memory controller lives on the processor, so memory instability and core instability are not cleanly separable - ruling memory out narrows things usefully.

  5. Rule out the power supply

    Effort: Varies · Risk: Low

    If you can borrow a known-good supply with adequate headroom, run on it for a week. As a cheaper diagnostic, cap CPU power limits in firmware - if the crashes stop at reduced power, the fault is in delivery rather than in the processor.

  6. Hunt a driver deadlock with Verifier

    Effort: Several hours · Risk: Medium

    Only worth doing after stock settings, temperatures and power have been eliminated. Enable Driver Verifier for non-Microsoft drivers with Force IRQL checking and Deadlock Detection, use the machine until it bugchecks, then read the dump and run verifier /reset.

    Watch out

    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 processor or its power delivery is genuinely at fault:

The WHEA correlation is the strongest single indicator. This bugcheck and 0x124 are two different mechanisms noticing the same underlying electrical problem - a watchdog spotting a core that went quiet, and the processor's own error reporting spotting a fault it could not correct. Seeing both on one machine, at stock settings, is about as clear as consumer-level hardware evidence gets. Keep the dumps and export the WHEA history before you talk to anyone about a replacement.

Frequently asked

My undervolt passed hours of stress testing. How can it be unstable?

Because stress tests exercise the wrong condition. A sustained all-core load pushes the processor to high current and moderate clocks, where an undervolt has plenty of margin. Light, bursty desktop work does the opposite: single cores boost to their maximum frequency at low current, which is where an aggressive offset runs out of voltage. That is why these crashes so often happen while browsing rather than while gaming - and why passing Prime95 proves considerably less than people assume.

It happens at idle. Surely idle is the easiest condition?

Electrically, no. At idle the processor is constantly entering and leaving low-power states, and single cores spike to peak boost clocks for short bursts. Those transitions are the hardest moments for voltage regulation to track. Idle crashes are a recognised signature of insufficient voltage, not an argument against it.

Can a driver really hang an entire CPU core?

Yes. Code holding a spinlock at high IRQL blocks that processor entirely until it releases, and if it never does, the core stops answering clock interrupts. Microsoft's resolution guidance points at exactly this - examining processor states, IRQL and the running code to find what is preventing forward execution. It is a real cause and worth pursuing, just not before the electrical ones.

How is this different from DPC_WATCHDOG_VIOLATION?

Both are watchdogs, watching different things. 0x133 fires when a deferred procedure call runs too long - the processor is executing, just stuck in one routine, and the cause is usually a storage or network driver. 0x101 fires when a core stops responding at all. The first is a software timing problem; the second usually means the core is not executing correctly, which is a hardware or voltage problem.