Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix 0x00000101

CLOCK_WATCHDOG_TIMEOUT 0x00000101 – a CPU core stopped responding

11 min read Updated October 5, 2026 Windows Crashes & Boot Recovery

Fix it now

0x00000101 means an expected clock interrupt on a secondary processor in a multi-processor system was not received in time. Microsoft’s published cause is that the processor is not processing interrupts, typically because it is unresponsive or deadlocked – which puts a spinning driver in scope alongside unstable hardware.

Run this in an elevated Command Prompt to read the 40 most recent System log entries

wevtutil qe System /c:40 /rd:true /f:text
  1. Undo any overclock or automatic tuning in firmware, including memory profiles, and retest at stock settings.
  2. Update the system firmware from the machine or board vendor. On a virtual machine, check the host instead – a stalled host is what a guest sees as a missed clock interrupt.
  3. Open the newest dump in WinDbg. Parameter 3 is the processor control block address of the unresponsive processor and parameter 4 is its index, which tells you whether it is always the same core.
  4. Run !analyze -v, then !prcb <index>, !pcr <index> and !irql <index> to see what that processor was doing and at which IRQL.
  5. If a third-party driver is on that processor’s stack, update or remove it. If the machine is a server with a storage or virtualisation agent, that is the first place to look.

Do not stop at the hardware story. Microsoft’s own resolution for this code is entirely debugger work aimed at finding the code that is not allowing forward execution.

If the machine is stable at stock firmware settings with current drivers, stop here. The next section covers reading the dump and the neighbouring watchdog codes.

Why it happens

On a multi-processor system one processor keeps the clock and the others are expected to take a periodic clock interrupt from it. Missing one is not fatal in itself, but a processor that has stopped taking interrupts altogether cannot be scheduled, cannot be interrupted, and cannot be recovered. The clock watchdog gives it an interval and then bug checks.

Microsoft’s wording is narrower than the way this code is usually described. It is an expected clock interrupt on a secondary processor, in a multi-processor system, not received within the allocated interval; and the published cause is that the specified processor is not processing interrupts, typically because it is unresponsive or deadlocked. That is a description of a stuck processor, and code can make a processor stuck just as reliably as bad silicon can.

The parameters are the way in. Parameter 1 is the timeout interval in nominal clock ticks, parameter 3 is the PRCB address of the unresponsive processor, and parameter 4 is its index. If the same index appears across several dumps you are looking at one physical core; if it moves around, you are looking at something that can stall any of them, which is more typical of a driver or a power-management interaction than of a defective core.

The neighbouring codes describe related but different stalls. 0x00000102 is the DPC watchdog: either an interrupt service routine hung at an IRQL below clock level and above dispatch level, or a DPC routine hung on the named processor, with parameter 2 the PRCB of the hung processor. 0x000001DB is a processor stuck in an inter-processor interrupt loop beyond the allowed time. 0x0000002E is a data bus error, typically a parity error in system memory. 0x0000005D means Windows is being asked to run on a processor it does not support.

The machine is running outside stock settings

You have this one if A memory profile, base clock change, voltage offset or board automatic tuning is enabled, and crashes appear under load or at idle transitions.

  1. Load firmware defaults and retest with nothing enabled.
  2. Reintroduce settings one at a time if the machine is stable at stock.
  3. Update the firmware while you are in there, then retest before adding anything back.
  4. Treat memory profiles as overclocks – they are the most common single cause of a machine that is stable at defaults and not otherwise.

A driver holding a processor and not letting go

You have this one if Firmware is current and stock, and the dump shows a third-party module on the unresponsive processor’s stack. The processor index varies between crashes.

  1. Read the stack for the processor named by parameter 4, not the stack of the processor that raised the bug check.
  2. Update the driver from its vendor, or remove the product that supplies it and confirm the machine is stable without it.
  3. On a test machine, run the standard Driver Verifier option set against the suspect drivers – deadlock detection is part of it.
  4. Where the driver belongs to a storage, virtualisation or endpoint agent, check the vendor supports that build on your Windows version.

The processor or the platform is genuinely failing

You have this one if The same processor index every time, no overclock, current firmware, and 0x00000124 also appears in the history.

  1. Run the manufacturer’s own hardware diagnostics, and Windows Memory Diagnostics with the extended test mix.
  2. Check cooling and thermal contact – a processor throttling hard or overheating can stall.
  3. If the machine takes more than one processor, swap or remove one to see whether the fault follows.
  4. Take the dump and the repeated processor index to the vendor. A consistent index is good evidence.

An unsupported processor configuration

You have this one if The code is 0x0000005D rather than 0x00000101, usually on a new build or after a processor swap.

  1. Read it literally: the computer is attempting to run Windows on an unsupported processor, and Windows requires a higher-grade processor than the one fitted.
  2. Check the processor against the Windows edition’s own requirements before anything else.
  3. Update firmware, which is what teaches an older board about a newer processor.
  4. Where this is a virtual machine, check the host’s processor compatibility settings for the guest.

Full reference

The parameters on the two watchdog codes

Code Parameter 1 Parameter 2 Parameter 3 Parameter 4
0x00000101 Clock interrupt timeout interval in nominal clock ticks 0 PRCB address of the unresponsive processor Index of the hung processor
0x00000102 DPC watchdog timeout interval in nominal clock ticks PRCB address of the hung processor Reserved Reserved
0x000001DB QPC frequency Current QPC Baseline QPC Reserved

Working the dump

Command What it shows
!analyze -v The automated analysis, and the processor involved
k, kb, kv The stack backtrace; specify the processor to see the stuck one
!prcb The processor control block for a given processor
!pcr The processor control region
!irql The current IRQL on a given processor

The whole of Microsoft’s published resolution for 0x00000101 is this list, used to investigate processor states, IRQL level and the code that is running, in order to determine which piece of code is not allowing forward execution. That framing is worth keeping: the question is not which component is broken, it is which code stopped moving.

0x00000102 and the storage stack

The DPC watchdog page carries a worked example that explains a lot of real-world cases. For StorPort miniport drivers, storport.sys handles I/O completions in a routine that runs at DISPATCH_LEVEL and serially calls the completion routines of every IRP that has just completed. If those completion routines take too long, singly or together, input stops responding and the DPC watchdog eventually decides the StorPort routine has taken excessive time. The documented remedy on the driver side is to queue a work element and return STATUS_MORE_PROCESSING_REQUIRED rather than doing everything in the completion routine – which is another way of saying that on a machine you own, the storage driver is the thing to update.

0x0000002E is a different fault wearing similar clothes

DATA_BUS_ERROR is typically a parity error in system memory. The documented causes are defective memory, including L2 cache and video RAM, hard disk corruption causing the error, and a device driver accessing an address in the 0x8xxxxxxx range that has no physical mapping. It is not a scheduling problem, and the debugger work above will not help with it – memory and driver testing will.

When it only happens on a virtual machine

  • Check the host first. A guest sees host stalls as missed clock interrupts, and the guest’s dump will not name the host’s cause.
  • Look at host storage latency and host processor contention over the period of the guest crash.
  • Confirm the guest’s integration or tools package matches the host version.
  • Check whether the guest has more virtual processors than the host can schedule promptly under its current load.
  • 0x000001DB in a guest is worth reading literally – a processor stuck in an inter-processor interrupt loop – which on a virtualised system is often a scheduling problem rather than a hardware one.

Every code this article covers

Code What it points at Source
0x00000101 CLOCK_WATCHDOG_TIMEOUT: an expected clock interrupt on a secondary processor in a multi-processor system was not received within the allocated interval. The published cause is that the processor is not processing interrupts, typically because it is unresponsive or deadlocked. Parameter 3 is its PRCB address and parameter 4 its index Microsoft Learn
0x0000005D UNSUPPORTED_PROCESSOR: the computer is attempting to run Windows on an unsupported processor. The published cause is that Windows requires a higher-grade processor than the one fitted Microsoft Learn
0x0000002E DATA_BUS_ERROR: typically a parity error in system memory. Documented causes include defective RAM, L2 cache and video RAM errors, hard disk corruption, and a driver accessing an address in the 0x8xxxxxxx range with no physical mapping Microsoft Learn
0x00000102 DPC_WATCHDOG_TIMEOUT: the DPC watchdog routine was not executed within the allocated interval – either an ISR is hung at an IRQL below clock level and above dispatch level, or a DPC routine is hung on the named processor. Parameter 2 is the PRCB address of the hung processor Microsoft Learn
0x000001DB IPI_WATCHDOG_TIMEOUT: a processor has been stuck in an inter-processor interrupt loop for more than the allowed time. The parameters carry the QPC frequency, the current QPC and the baseline QPC Microsoft Learn

Confirm the fix worked

  1. Firmware is at stock settings with no profile enabled and the machine survives a sustained multi-threaded load test.
  2. System firmware and chipset drivers are at the versions currently published for the model.
  3. No new BugCheck events appear in the System log over several days of normal use.
  4. If a driver was replaced, the workload that used to stall the machine runs to completion twice.
  5. On a virtual machine, the host shows no storage latency or processor contention over the same period.

Questions people ask about this

Is 0x00000101 always a hardware fault?

No. The published cause is a processor that is not processing interrupts, typically unresponsive or deadlocked, and Microsoft’s entire resolution section is debugger work aimed at finding the code that is not allowing forward execution. Unstable hardware is a strong candidate, but a spinning driver produces the same symptom.

The same processor index appears every time. What does that mean?

It is good evidence for a specific physical core rather than a driver, because a driver can stall whichever processor it happens to be running on. Take the repeated index and the dump to the hardware vendor.

Is 0x00000102 the same problem?

Related, not the same. The DPC watchdog fires when an interrupt service routine is hung between dispatch and clock level, or a DPC routine is hung, rather than when a processor has stopped taking clock interrupts entirely. On real machines it very often points at the storage stack.

What is 0x000001DB?

A processor stuck in an inter-processor interrupt loop for longer than the allowed time. It is a genuinely different failure from a missed clock interrupt, so read it as its own thing rather than as a variant of 0x101.

Does a BIOS update fix this?

Often, and it is worth doing early because it is cheap and reversible in effect. Microsoft does not publish microcode as the mechanism for this code, so treat the firmware update as a general step rather than as a specific cure.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix DPC_WATCHDOG_VIOLATION 0x00000133 – PC freezes then blue screens Free Fix MANUALLY_INITIATED_CRASH 0x000000E2 and missing memory dump files License Error 0xC0000102 file corrupt error when repairing or reinstalling Windows Free Fix VIDEO_TDR_FAILURE 0x00000116 – display driver stopped responding
← Back to Knowledge Base