1. #1

    BSOD(A clock interrupt was not recieved on a secondary processor...)

    ​Hi everyone!
    I'm having a BSOD "A clock interrupt was not recieved on a secondary processor within the allocated time interval" in 10-15 seconds after loading. If someone help me with this problem I'll be really thankful! Thank you so much in advance!

    OS - Windows 8.1, 8, 7, Vista ? - I have Windows 7
    x86 (32-bit) or x64 ? - x86(32-bit)
    What was original installed OS on system? - Windows XP
    Is the OS an OEM version (came pre-installed on system) or full retail version (YOU purchased it from retailer)? - Came pre-installed on system
    Age of system (hardware) - 7-8 years
    Age of OS installation - have you re-installed the OS? I reinstalled the OS about 2 month ago

    CPU -
    DualCore AMD Athlon 64 X2, 2753 MHz (15 x 184)
    Video Card -
    nVIDIA nForce 7025-630a
    MotherBoard -
    asrock n68c -gs fx
    Power Supply - brand & wattage (if laptop, skip this one) - I couldn't find this information

    System Manufacturer - I'm not sure
    Exact model number (if laptop, check label on bottom) - I don't know, sorry

    Laptop or Desktop? - Desktop


    Attached Files Attached Files


    • Ad Bot

      advertising
      Beep.

        
       

  2. #2
    x BlueRobot's Avatar
    Join Date
    May 2013
    Location
    Minkowski Space
    Posts
    1,651

    Re: BSOD(A clock interrupt was not recieved on a secondary processor...)

    Please check this directory (C:\Windows\MEMORY.DMP) for Kernel Memory Dumps, and then upload to a free file sharing site such as Dropbox or OneDrive (SkyDrive), and then post the link to the file in your next post. Please ensure that the Kernel Memory Dump is placed within a zipped folder in order to decrease the download/upload times.
    Last edited by x BlueRobot; 04-23-2014 at 01:18 PM.
    Machines Can Think

    Oxygen, Nature's paradox.

  3. #3

    Re: BSOD(A clock interrupt was not recieved on a secondary processor...)


  4. #4

    Re: BSOD(A clock interrupt was not recieved on a secondary processor...)

    Hi,

    Not to take away from Harry's post, because I am sure he has a few things to chime in on in addition to what I may find...

    CLOCK_WATCHDOG_TIMEOUT (101)

    This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.

    Code:
    BugCheck 101, {60, 0, 807c5120, 1}
    ^^ 60 clock ticks in regards to the timeout.

    Code:
    0: kd> !prcb 1
    PRCB for Processor 1 at 807c5120:
    Current IRQL -- 0
    Threads--  Current 8519bd48 Next 85140958 Idle 807ca800
    Processor Index 1 Number (0, 1) GroupSetMember 2
    Interrupt Count -- 00034cdd
    Times -- Dpc    00000058 Interrupt 00000048 
             Kernel 000020aa User      000004b9
    As this matches the 3rd parameter of the bug check, processor #1 is the responsible processor. Now with the information we have here thus far, we know that processor #1 reached 60 clock ticks without responding, therefore the system crashed. Before we go further, what is a clock tick? A clock interrupt is a form of interrupt which involves counting the the cycles of the processor core, which is running a clock on the processors to keep them all in sync. A clock interrupt is handed out to all processors and then they must report in, and when one doesn't report in, you then crash.



    Code:
    0: kd> kv
    ChildEBP RetAddr  Args to Child              
    90a738e4 82a82a1f 00000101 00000060 00000000 nt!KeBugCheckEx+0x1e
    90a73920 82a8206e 00002626 00000000 00002700 nt!KeAccumulateTicks+0x242
    90a73960 82a81f1b 82a3ec5e 4b40880d 00000000 nt!KeUpdateRunTime+0x145
    90a739b8 82a86bb7 0000041b 0000041b 000000d1 nt!KeUpdateSystemTime+0x613
    90a739b8 82a3ec5e 0000041b 0000041b 000000d1 nt!KeUpdateSystemTimeAssist+0x13 (FPO: [0,2] TrapFrame @ 90a739cc)
    90a73a5c 82ab91a7 a7cdf000 00000000 90a73aac nt!KeFlushMultipleRangeTb+0x2d5
    90a73b3c 82aa5ca9 c053e700 00000008 00000000 nt!MiFlushTbAsNeeded+0x12e
    90a73b7c 82b26487 00027cd8 00000001 84f79000 nt!MiAllocatePagedPoolPages+0x567
    90a73be0 82aa260d 00000001 00008000 00000ff0 nt!MiAllocatePoolPages+0x1f
    90a73c38 82b27132 00000000 00000001 00008000 nt!ExpAllocateBigPool+0xa6
    90a73c9c 82aaeb89 00000001 00008000 20207050 nt!ExAllocatePoolWithTag+0x12d
    90a73cc0 82beb8c9 86d80630 00008000 20207050 nt!ExAllocatePoolWithQuotaTag+0x57
    90a73cf0 82beb6b6 00000009 a2462f88 00000018 nt!PiControlGetInterfaceDeviceList+0x86
    90a73d20 82a4527a 00000009 0149f5d0 00000018 nt!NtPlugPlayControl+0xbe
    90a73d20 775170b4 00000009 0149f5d0 00000018 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 90a73d34)
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    0149f608 00000000 00000000 00000000 00000000 0x775170b4
    Code:
    0: kd> .trap 90a739cc
    ErrCode = 00000000
    eax=00000002 ebx=00000001 ecx=a7cdf000 edx=00000000 esi=d7b9f00e edi=82b3358c
    eip=82a3ec5e esp=90a73a40 ebp=90a73a5c iopl=0         nv up ei ng nz na po nc
    cs=0008  ss=0010  ds=0000  es=0001  fs=0fff  gs=8f07             efl=00000282
    nt!KeFlushMultipleRangeTb+0x2d5:
    82a3ec5e 8b07            mov     eax,dword ptr [edi]       ds:82b3358c=00000002
    Code:
    0: kd> u @eip
    nt!KeFlushMultipleRangeTb+0x2d5:
    82a3ec5e 8b07            mov     eax,dword ptr [edi]
    82a3ec60 85c0            test    eax,eax
    82a3ec62 75de            jne     nt!KeFlushMultipleRangeTb+0x2b9 (82a3ec42)
    82a3ec64 8a4d0f          mov     cl,byte ptr [ebp+0Fh]
    82a3ec67 ff155881a082    call    dword ptr [nt!_imp_KfLowerIrql (82a08158)]
    82a3ec6d 5f              pop     edi
    82a3ec6e 5e              pop     esi
    82a3ec6f 5b              pop     ebx
    Code:
    0: kd> u 82a3ec42 82a3ec64
    nt!KeFlushMultipleRangeTb+0x2b9:
    82a3ec42 46              inc     esi
    82a3ec43 8535c40bb782    test    dword ptr [nt!HvlLongSpinCountMask (82b70bc4)],esi
    82a3ec49 7511            jne     nt!KeFlushMultipleRangeTb+0x2d3 (82a3ec5c) <--- Takes the jump (jmp) to stay in a loop.
    82a3ec4b f605bc0bb78240  test    byte ptr [nt!HvlEnlightenments (82b70bbc)],40h
    82a3ec52 7408            je      nt!KeFlushMultipleRangeTb+0x2d3 (82a3ec5c)
    82a3ec54 56              push    esi
    82a3ec55 e865080a00      call    nt!HvlNotifyLongSpinWait (82adf4bf)
    82a3ec5a eb02            jmp     nt!KeFlushMultipleRangeTb+0x2d5 (82a3ec5e)
    82a3ec5c f390            pause <--- Executing a pause (a CPU delay), and doing this in a loop waiting for a release.
    82a3ec5e 8b07            mov     eax,dword ptr [edi]
    82a3ec60 85c0            test    eax,eax <--- Checking if value is non-zero.
    82a3ec62 75de            jne     nt!KeFlushMultipleRangeTb+0x2b9 (82a3ec42)
    82a3ec64 8a4d0f          mov     cl,byte ptr [ebp+0Fh]
    Okay, so what's causing the loop? We'll need to dump the other call stacks to try and get an idea.



    Code:
    0: kd> ~1
    WARNING: Process directory table base AEAC25A0 doesn't match CR3 00185000
    WARNING: Process directory table base AEAC25A0 doesn't match CR3 00185000
    Code:
    1: kd> kv
    ChildEBP RetAddr  Args to Child              
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    00000000 00000000 00000000 00000000 00000000 0x0
    Okay, so here we have the problematic processor, which is all zeroed out, plus the process directory table doesn't match. We'll need to dump the raw stack.

    Code:
    1: kd> !pcr
    KPCR for Processor 1 at 807c5000:
        Major 1 Minor 1
        NtTib.ExceptionList: 9efb3b60
            NtTib.StackBase: 00000000
           NtTib.StackLimit: 00000000
         NtTib.SubSystemTib: 807c8750
              NtTib.Version: 0006ce50
          NtTib.UserPointer: 00000002
              NtTib.SelfTib: 7ffdf000
    
                    SelfPcr: 807c5000
                       Prcb: 807c5120
                       Irql: 00000000
                        IRR: 00000000
                        IDR: ffffffff
              InterruptMode: 00000000
                        IDT: 807ce020
                        GDT: 807cdc20
                        TSS: 807c8750
    
              CurrentThread: 8519bd48
                 NextThread: 85140958
                 IdleThread: 807ca800
    
                  DpcQueue:  0x807c8520 0x82afaf0f [Normal] nt!PpmPerfAction
    Code:
    1: kd> !thread
    THREAD 8519bd48  Cid 0f80.0f28  Teb: 7ffdf000 Win32Thread: fe98c9c0 RUNNING on processor 1
    Not impersonating
    DeviceMap                 8bfa1470
    Owning Process            851afd40       Image:         Isaac.exe
    Attached Process          N/A            Image:         N/A
    Wait Start TickCount      9687           Ticks: 401 (0:00:00:06.265)
    Context Switch Count      18083          IdealProcessor: 0             
    UserTime                  00:00:13.578
    KernelTime                00:00:02.000
    Win32 Start Address 0x00b657f0
    Stack Init 9ee17fd0 Current 9ee17bc8 Base 9ee18000 Limit 9ee15000 Call 500
    Priority 12 BasePriority 8 UnusualBoost 0 ForegroundBoost 2 IoPriority 2 PagePriority 5
    ChildEBP RetAddr  Args to Child              
    00000000 00000000 00000000 00000000 00000000 0x0
    Code:
    
    9ee1640c  82a894c0 nt!SepSidInTokenSidHash+0x40
    9ee16410  9ee166a8
    9ee16414  010954b8
    9ee16418  00000000
    9ee1641c  9ee16438
    9ee16420  82a89476 nt!SepSidInToken+0x29
    9ee16424  00000000
    9ee16428  00000000
    9ee16434  860954b0
    9ee16438  9ee16464
    9ee1643c  82a89279 nt!SepNormalAccessCheck+0x6c
    9ee16440  00000000
    9ee16464  9ee1650c
    9ee16468  82a88eba nt!SepAccessCheck+0x1f9
    9ee1646c  00000001
    9ee16484  9ee1650c
    9ee16488  82a88f05 nt!SepAccessCheck+0x244
    9ee1648c  82a8916b nt!SepAccessCheck+0x4a8
    9ee16490  9ee169f8
    9ee16494  9ee165d0
    9ee16498  82a89202 nt!SepAccessCheck+0x539
    9ee1649c  8201916b
    9ee1650c  9ee16574
    9ee16510  82a88c74 nt!SeAccessCheckWithHint+0x1f1
    9ee16514  86095494
    9ee16568  00000003
    9ee1656c  82a9e700 nt!RtlpPopulateContext+0xa
    9ee16570  9ee165e0
    9ee16574  9ee169ac
    9ee16578  82a9ea99 nt!SeAccessCheckFromState+0xea
    9ee1657c  01095494
    9ee165ac  00000000
    9ee165b0  82a9eaaa nt!SeAccessCheckFromState+0xfb
    9ee17058  82e24615 hal!HalpGetPmTimerPerfCounterValue+0x29
    9ee1705c  00000508
    9ee17070  9ee17080
    9ee17074  82e24b8c hal!HalpPmTimerQueryPerformanceCounter+0x42
    9ee17078  86cd0000
    9ee17088  ffffff00
    9ee1708c  91781b51 dxgmms1!VidSchiUpdateContextRunningTimeAtISR+0x69
    9ee17090  e069d700
    9ee170ac  9ee17104
    9ee170b0  91783735 dxgmms1!VidSchiProcessIsrCompletedPacket+0x1d5
    9ee170b4  00000008
    9ee170c8  9ee17104
    9ee170cc  86cd09d0
    9ee170d0  91783744 dxgmms1!VidSchiProcessIsrCompletedPacket+0x1e4
    9ee170d4  86cc4008
    9ee170d8  86cd0000
    9ee17100  00000000
    9ee17104  9ee17134
    9ee17108  91785952 dxgmms1!VidSchDdiNotifyInterruptWorker+0x1b2
    9ee1710c  86cc4008
    9ee17128  86447000
    9ee1712c  91471728*** ERROR: Symbol file could not be found.  Defaulted to export symbols for nvlddmkm.sys - 
     nvlddmkm!nvDumpConfig+0x1d6a60
    9ee17130  00000000
    9ee17134  9ee17198
    9ee17138  90cd0434 nvlddmkm+0x97434
    I didn't dump the entire raw stack, but there were also some network related routines. Right, so interrupts aren't processed on a separate stack, and is generally delivered on the existing stack (as we can see above). However, before the DPC queue is drained, it swaps to a dedicated stack specific for DPC processing. I believe this may be because the CPU is so behind at this current time.

    Code:
    1: kd> !dpcs
    CPU Type      KDPC       Function
     1: Normal  : 0x807c8520 0x82afaf0f nt!PpmPerfAction
    We can confirm that it is very behind by checking whether or not we have any pending DPCs, which we do. Not good at all to ever have any pending DPCs.



    1. Ensure you have the latest video card drivers. If you are already on the latest video card drivers, uninstall and install a version or a few versions behind the latest to ensure it's not a latest driver only issue. If you have already experimented with the latest video card driver and many previous versions, please give the beta driver for your card a try.

    2.

    Code:
    0: kd> lmvm VSTCNXT3
    start    end        module name
    8f228000 8f2dd000   VSTCNXT3   (deferred)             
        Image path: \SystemRoot\system32\DRIVERS\VSTCNXT3.SYS
        Image name: VSTCNXT3.SYS
        Timestamp:        Wed Oct 15 17:29:13 2008
    ^^ Conexant SoftK56 Modem driver. Once you reach I'd say Windows 7, these device drivers just don't behave properly at all. I recommend replacing this modem and purchasing a more up-to-date method of connecting to the internet ASAP. It might be contributing to the problem here given the network routines in the raw stack.

    3. If the above do not help, I am going to go ahead and say this is a faulty processor.

    Regards,

    Patrick

  5. #5

    Re: BSOD(A clock interrupt was not recieved on a secondary processor...)

    Thank you for the help! I'll try to reinstall video card drivers. Today I noticed that if I decrease the CPU frequency in BIOS from default(200) to 180 or 185 Windows runs well without the blue screen but FPS in every game becomes very small(10-5).

  6. #6

    Re: BSOD(A clock interrupt was not recieved on a secondary processor...)

    I wouldn't mess with that, and I'd go ahead and either set it back, or load BIOS defaults (I'd recommend the latter).

    Regards,

    Patrick

  7. #7
    x BlueRobot's Avatar
    Join Date
    May 2013
    Location
    Minkowski Space
    Posts
    1,651

    Re: BSOD(A clock interrupt was not recieved on a secondary processor...)

    Code:
    0: kd> ~1
    WARNING: Process directory table base AEAC25A0 doesn't match CR3 00185000
    WARNING: Process directory table base AEAC25A0 doesn't match CR3 00185000
    The Process Directory Table Base is private to each Process Address Space and is used with conjunction to the TLB Cache and TLB Flushing. It's all the virtual address pages which correspond to that process, and thus when a Context Switch occurs, then the Control Register can be changed to the address of the process and all the entries within the TLB Cache are flushed.

    Code:
    1: kd> r @CR3
    cr3=00185000
    Code:
    1: kd> !process
    PROCESS 851afd40  SessionId: 1  Cid: 0f80    Peb: 7ffd5000  ParentCid: 0e28
        DirBase: aeac25a0  ObjectTable: a4be2208  HandleCount: 319.
        Image: Isaac.exe
        VadRoot 8519f410 Vads 255 Clone 0 Private 38805. Modified 61771. Locked 0.
        DeviceMap 8bfa1470
        Token                             a4e12c88
        ElapsedTime                       00:00:30.083
        UserTime                          00:00:00.000
        KernelTime                        00:00:00.000
        QuotaPoolUsage[PagedPool]         295980
        QuotaPoolUsage[NonPagedPool]      15380
        Working Set Sizes (now,min,max)  (9025, 50, 345) (36100KB, 200KB, 1380KB)
        PeakWorkingSetSize                44700
        VirtualSize                       337 Mb
        PeakVirtualSize                   337 Mb
        PageFaultCount                    76799
        MemoryPriority                    BACKGROUND
        BasePriority                      8
        CommitCharge                      47116
    The DirBase field is the field within structure formatted with !process, which contains the address of the Process Directory Table Base for the current process, and thus if the two addresses don't match, then WinDbg will produce that error string. It tends to be caused when a crash occurs during a context switch.

    Code:
    1: kd> dt nt!_KPROCESS
       +0x000 Header           : _DISPATCHER_HEADER
       +0x010 ProfileListHead  : _LIST_ENTRY
       +0x018 DirectoryTableBase : Uint4B
       +0x01c LdtDescriptor    : _KGDTENTRY
       +0x024 Int21Descriptor  : _KIDTENTRY
       +0x02c ThreadListHead   : _LIST_ENTRY
       +0x034 ProcessLock      : Uint4B
       +0x038 Affinity         : _KAFFINITY_EX
       +0x044 ReadyListHead    : _LIST_ENTRY
       +0x04c SwapListEntry    : _SINGLE_LIST_ENTRY
       +0x050 ActiveProcessors : _KAFFINITY_EX
       +0x05c AutoAlignment    : Pos 0, 1 Bit
       +0x05c DisableBoost     : Pos 1, 1 Bit
       +0x05c DisableQuantum   : Pos 2, 1 Bit
       +0x05c ActiveGroupsMask : Pos 3, 1 Bit
       +0x05c ReservedFlags    : Pos 4, 28 Bits
       +0x05c ProcessFlags     : Int4B
       +0x060 BasePriority     : Char
       +0x061 QuantumReset     : Char
       +0x062 Visited          : UChar
       +0x063 Unused3          : UChar
       +0x064 ThreadSeed       : [1] Uint4B
       +0x068 IdealNode        : [1] Uint2B
       +0x06a IdealGlobalNode  : Uint2B
       +0x06c Flags            : _KEXECUTE_OPTIONS
       +0x06d Unused1          : UChar
       +0x06e IopmOffset       : Uint2B
       +0x070 Unused4          : Uint4B
       +0x074 StackCount       : _KSTACK_COUNT
       +0x078 ProcessListEntry : _LIST_ENTRY
       +0x080 CycleTime        : Uint8B
       +0x088 KernelTime       : Uint4B
       +0x08c UserTime         : Uint4B
       +0x090 VdmTrapcHandler  : Ptr32 Void
    Machines Can Think

    Oxygen, Nature's paradox.

  8. #8
    x BlueRobot's Avatar
    Join Date
    May 2013
    Location
    Minkowski Space
    Posts
    1,651

    Re: BSOD(A clock interrupt was not recieved on a secondary processor...)

    The Zeroed Stack can be for optimisation reasons, but I'm not entirely sure about this in Kernel Mode.
    Machines Can Think

    Oxygen, Nature's paradox.

Similar Threads

  1. [BSOD] Clock Interrupt was not received on a secondary processor
    By AlexL in forum BSOD, Crashes, Kernel Debugging
    Replies: 3
    Last Post: 01-21-2014, 05:14 PM
  2. BSOD Clock interrupt was not receieved on a secondary processor
    By tramsden in forum BSOD, Crashes, Kernel Debugging
    Replies: 1
    Last Post: 01-12-2014, 06:38 PM
  3. BSOD -- Clock interrupt not received on a secondary processor
    By achkas in forum BSOD, Crashes, Kernel Debugging
    Replies: 12
    Last Post: 11-30-2013, 08:45 PM
  4. BSOD A clock interrupt was not received on a secondary processor
    By Gus Erlangga in forum BSOD, Crashes, Kernel Debugging
    Replies: 9
    Last Post: 11-30-2013, 07:18 PM
  5. BSOD A clock interrupt was not received on a secondary processor
    By Gus Erlangga in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 3
    Last Post: 11-27-2013, 05:04 AM

Log in

Log in