CLOCK_WATCHDOG_TIMEOUT (101)

Sabrina R de Carvalho 0 Reputation points
2023-07-18T18:02:31.86+00:00
************* Preparing the environment for Debugger Extensions Gallery repositories **************
   ExtensionRepository : Implicit
   UseExperimentalFeatureForNugetShare : false
   AllowNugetExeUpdate : false
   AllowNugetMSCredentialProviderInstall : false
   AllowParallelInitializationOfLocalRepositories : true

   -- Configuring repositories
      ----> Repository : LocalInstalled, Enabled: true
      ----> Repository : UserExtensions, Enabled: true

>>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.016 seconds

************* Waiting for Debugger Extensions Gallery to Initialize **************

>>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.046 seconds
   ----> Repository : UserExtensions, Enabled: true, Packages count: 0
   ----> Repository : LocalInstalled, Enabled: true, Packages count: 36

Microsoft (R) Windows Debugger Version 10.0.25877.1004 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Jomuel\Documents\071723-12718-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
Windows 10 Kernel Version 19041 MP (16 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Kernel base = 0xfffff806`12e00000 PsLoadedModuleList = 0xfffff806`13a2a2d0
Debug session time: Mon Jul 17 16:51:29.431 2023 (UTC - 3:00)
System Uptime: 0 days 0:05:51.156
Loading Kernel Symbols
...............................................................
................................................................
...................................
Loading User Symbols

Loading unloaded module list
.........
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff806`131fc0c0 48894c2408      mov     qword ptr [rsp+8],rcx ss:0018:fffff806`15a82c90=0000000000000101
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 000000000000000c, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffff9881f77d7180, The PRCB address of the hung processor.
Arg4: 0000000000000006, The index of the hung processor.

Debugging Details:
------------------

*** WARNING: Check Image - Checksum mismatch - Dump: 0x18561b, File: 0x1857e3 - C:\ProgramData\Dbg\sym\BTHport.sys\70388B82185000\BTHport.sys

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 5140

    Key  : Analysis.Elapsed.mSec
    Value: 8015

    Key  : Analysis.IO.Other.Mb
    Value: 0

    Key  : Analysis.IO.Read.Mb
    Value: 0

    Key  : Analysis.IO.Write.Mb
    Value: 0

    Key  : Analysis.Init.CPU.mSec
    Value: 858

    Key  : Analysis.Init.Elapsed.mSec
    Value: 28491

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 96

    Key  : Bugcheck.Code.LegacyAPI
    Value: 0x101

    Key  : Failure.Bucket
    Value: CLOCK_WATCHDOG_TIMEOUT_IDLE_THREAD_nt!KeAccumulateTicks

    Key  : Failure.Hash
    Value: {258f356e-b219-deec-be32-7461c52c1aae}

    Key  : WER.OS.Branch
    Value: vb_release

    Key  : WER.OS.Version
    Value: 10.0.19041.1


BUGCHECK_CODE:  101

BUGCHECK_P1: c

BUGCHECK_P2: 0

BUGCHECK_P3: ffff9881f77d7180

BUGCHECK_P4: 6

FILE_IN_CAB:  071723-12718-01.dmp

FAULTING_PROCESSOR: 6

FAULTING_THREAD:  ffff9881f77e2440

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

STACK_TEXT:  
fffff806`15a82c88 fffff806`13243af6     : 00000000`00000101 00000000`0000000c 00000000`00000000 ffff9881`f77d7180 : nt!KeBugCheckEx
fffff806`15a82c90 fffff806`13086e3d     : 00000000`00000000 fffff806`0db4a180 00000000`00000246 00000000`000057ca : nt!KeAccumulateTicks+0x1bfed6
fffff806`15a82cf0 fffff806`1307dec1     : 00000000`00000000 00000000`00003453 fffff806`0db4a180 00000000`00000001 : nt!KiUpdateRunTime+0x5d
fffff806`15a82d40 fffff806`13081253     : fffff806`0db4a180 00000000`00000000 fffff806`13a31630 00000000`00000000 : nt!KiUpdateTime+0x4a1
fffff806`15a82e80 fffff806`13088ae2     : fffff806`15a74190 fffff806`15a74210 fffff806`15a74200 00000000`00000002 : nt!KeClockInterruptNotify+0x2e3
fffff806`15a82f30 fffff806`1313ec85     : 00000000`d16510e8 fffff806`13af3a60 fffff806`13af3b10 ffff6531`88f49ba4 : nt!HalpTimerClockInterrupt+0xe2
fffff806`15a82f60 fffff806`131fe05a     : fffff806`15a74210 fffff806`13af3a60 00000000`00000000 00000000`00000000 : nt!KiCallInterruptServiceRoutine+0xa5
fffff806`15a82fb0 fffff806`131fe827     : fffff806`00000000 00001f80`001f0234 fffff781`c00015a1 fffff806`15a74360 : nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
fffff806`15a74190 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiInterruptDispatchNoLockNoEtw+0x37


STACK_COMMAND:  .thread 0xffff9881f77e2440 ; kb

SYMBOL_NAME:  nt!KeAccumulateTicks+1bfed6

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

IMAGE_VERSION:  10.0.19041.3208

BUCKET_ID_FUNC_OFFSET:  1bfed6

FAILURE_BUCKET_ID:  CLOCK_WATCHDOG_TIMEOUT_IDLE_THREAD_nt!KeAccumulateTicks

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {258f356e-b219-deec-be32-7461c52c1aae}

Followup:     MachineOwner
---------


Windows 10
Windows 10
A Microsoft operating system that runs on personal computers and tablets.
10,231 questions
{count} votes

2 answers

Sort by: Most helpful
  1. Limitless Technology 44,011 Reputation points
    2023-07-19T12:25:18.67+00:00

    Hello there,

    The CLOCK_WATCHDOG_TIMEOUT error (error code 101) is a blue screen of death (BSOD) error that typically occurs in Windows systems. It indicates that a processor core in your system took too long to respond to an interrupt request from the operating system.

    This error can be caused by several factors, including:

    Hardware Issues: It could be due to a faulty or incompatible hardware component, such as a malfunctioning CPU, motherboard, or power supply.

    Overclocking: If you have overclocked your CPU or other hardware components, it can lead to instability and trigger this error.

    Driver Problems: Outdated, incompatible, or corrupted device drivers can cause conflicts and result in the CLOCK_WATCHDOG_TIMEOUT error.

    Overheating: If your CPU or other components are overheating, it can lead to system instability and trigger this error.

    I used AI provided by ChatGPT to formulate part of this response. I have verified that the information is accurate before sharing it with you.

    Hope this resolves your Query !!

    --If the reply is helpful, please Upvote and Accept it as an answer--

    0 comments No comments

  2. Charles Gardiner 96 Reputation points
    2023-07-27T22:33:10.5033333+00:00

    I'm having the same problem with my customer's hardware. My current opinion is that a PCIe read request in the HW is not completing, causing a processor core to hang. The PCIe spec expects reads to complete within 50 ms but it looks like Windows only waits 32 ms (not sure about the 32 ms exactly but you probably get what I mean) which is legal. The PCIe spec specifies a minimum wait of 50us.

    However, I have also seen this error if two threads are blocking each other at a spin lock and one of the threads is an interrupt handler. Could you walk through the "Processes and Threads" window in the debugger and look at the stack trace in each case? If you see two threads trying to grab the same spin-lock ( or in some cases two calls from the same thread, if a procedure calls another procedure requiring the same lock) then I think you have found your problem.

    Are you compiling the driver yourself? If so, what might help is to enable OnTheFly logging in the VisualStudio project and look at the last command in the logfile:

    !wdfkd.wdfldr

    !wdflogdump <your_driver>.sys -d

    This has helped me sort out a few issues in my current project

    0 comments No comments