1. #1

    BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Hi, all -
    So glad to have found your forum. Since I installed Windows 7 on my machine, I have consistently been getting the BSOD stating that a clock interrupt was not received on a secondary processor , especially if I run any sort of graphics based FB game for any length of time and my wife has been having it happen when she opens up Outlook. Would appreciate your expertise. I've done my best to include the requested files. Let me know if you need anything else.

    Thanks,
    Christano
    Last edited by Christano; 02-15-2014 at 05:05 PM. Reason: adding further info


    • Ad Bot

      advertising
      Beep.

        
       

  2. #2

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Hi,

    We have many CLOCK_WATCHDOG_TIMEOUT (101) bug checks.

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

    Unfortunately, we'll need a kernel-dump to be able to analyze this bug check as not information is saved at the time of the crash within a minidump.

    Creating a Kernel-Mode Dump File (Windows Debuggers)

    After a kernel-dump is generated, you'll have to upload it to a 3rd party host such as Mediafire, Onedrive, Google Drive, etc. Whatever works best for you.

    Regards,

    Patrick

  3. #3

    Angry re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    I found the automatic Kernel Dump file, but have tried TWICE now to upload it to Google Drive. However, when it is between 25-50%, I get the BSOD because it is taking so long. Any suggestions for a quicker upload than Google Drive? I'm new to the Cloud drives...

    Thanks.

  4. #4

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    It's not so much the host you're uploading to, but likely your upload speed. You can try Mediafire or Onedrive, but if you notice the same speed, it's just simply capped at your upload speed. If you cannot upload it because you BSOD before then, consider booting into Safe Mode w/ Networking and trying there.

    Advanced startup options (including safe mode) - Microsoft Windows Help

    Regards,

    Patrick

  5. #5

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Okay - I've got it uploading to a dropbox file here: https://www.dropbox.com/s/l7c0f0vkzh...21416-2201.DMP

    It's still uploading, but hopefully will get in there before I have another BSOD.

    Thanks!

  6. #6

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    First off, let me start by saying that in the middle of debugging your kernel-dump, I accidentally hit F5 and refreshed the page.

    BSOD secondary processor - 0x101 - Windows 7 x64 SP1-i-love-sysnative-png
    ..then I saw this, the oasis in the desert

    Moving on, thanks very much for the kernel-dump. This is actually one of the most (if not the most) difficult debuggings I have done as it was not a fairly 'standard' *101, so this was a phenomenal experience for me. With *101 forum bug checks, in most cases, it isn't this hard, honestly. The call stacks on basic user systems are fairly to the point and are straight-forward without requiring much intensive debugging. Even with that, this isn't the type of bug check that's as easy as saying 'it was caused by this', you have to explain. I mean, technically you could, but that's no good for the user.



    Right, so as per usual, the attached DMP file is of the CLOCK_WATCHDOG_TIMEOUT (101) bugcheck.

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

    BugCheck 101, {31, 0, fffff88002fd3180, 3}

    31 clock ticks in regards to the timeout.

    fffff88002fd3180 is the PRCB address of the hung processor, let's keep this address in mind.

    Code:
    0: kd> !prcb 3
    PRCB for Processor 3 at fffff88002fd3180:
    Current IRQL -- 0
    Threads--  Current fffffa80077b29a0 Next fffffa8007368b50 Idle fffff88002fddfc0
    Processor Index 3 Number (0, 3) GroupSetMember 8
    Interrupt Count -- 0083298b
    Times -- Dpc    0000142d Interrupt 00000746 
             Kernel 00049f9a User      0000ce12
    For reference, I did not do !prcb 0 through 3. That would have been very tedious. Instead, you can run the !running -it command. The "i" argument causes it to display idle procs too, and "t" displays the stack trace for the thread running on each proc. Running that specific command shows you're on a 4 core box.

    Hint: At times, the 4th parameter of the bug check will show you the responsible processor. For example, in your *101 here, it was correct as the 4th parameter was 3.

    Hint #2: You can also generally tell the amount of cores on the box by checking the bugcheck_string - BUGCHECK_STR: CLOCK_WATCHDOG_TIMEOUT_4_PROC

    As this matches the 3rd parameter of the bugcheck, processor #3 is the responsible processor. Now with the information we have here thus far, we know that processor #3 reached 31 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.



    If we look specifically at processor #3, we can see it did...well... nothing:

    Code:
    3: kd> kv
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0
    If we check the IRQL of the problem processor:

    Code:
    3: kd> !irql 3
    Debugger saved IRQL for processor 0x3 -- 0 (LOW_LEVEL)
    We can also see the IRQL in the !prcb output seen earlier.

    Let's also check the rest:

    Proc 0:

    Code:
    0: kd> !prcb 0
    PRCB for Processor 0 at fffff80002df6e80:
    Current IRQL -- 13
    Threads--  Current fffffa8003747040 Next 0000000000000000 Idle fffff80002e04cc0
    Processor Index 0 Number (0, 0) GroupSetMember 1
    Interrupt Count -- 004e37d8
    Times -- Dpc    00000031 Interrupt 0000006b 
             Kernel 0004f290 User      00007dbd
    Proc 1:

    Code:
    0: kd> !prcb 1
    PRCB for Processor 1 at fffff880009e7180:
    Current IRQL -- 0
    Threads--  Current fffffa8007654330 Next fffffa8006863060 Idle fffff880009f1fc0
    Processor Index 1 Number (0, 1) GroupSetMember 2
    Interrupt Count -- 00538b04
    Times -- Dpc    00000024 Interrupt 00000088 
             Kernel 0004c3fc User      0000abfe
    Proc 2:

    Code:
    0: kd> !prcb 2
    PRCB for Processor 2 at fffff88002f63180:
    Current IRQL -- 0
    Threads--  Current fffffa80037b7660 Next 0000000000000000 Idle fffff88002f6dfc0
    Processor Index 2 Number (0, 2) GroupSetMember 4
    Interrupt Count -- 0052489a
    Times -- Dpc    00000139 Interrupt 000000de 
             Kernel 0004d305 User      00009ced
    So, from this, we can see that Processors 1, 2, and 3 were at IRQL 0. IRQL 0 = PASSIVE_LEVEL, which is where user threads and most kernel-mode operations take place. Any interrupt can occur at PASSIVE_LEVEL. User-mode code executes at PASSIVE_LEVEL.

    However, we can see that Processor 0 was at IRQL 13. IRQL 13 = CLOCK_LEVEL for x64 processors. On an 0x86 processor, CLOCK_LEVEL is 28.



    Let's now look at the stacks of the different processors to see what the threads were involved in:

    We can use knL and go through a grueling method of obtaining the trap frame, but we don't like having to put in more work, so let's use kv instead on Proc 0:

    Code:
    0: kd> kv
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    fffff880`03184a48 fffff800`02cd2a4a : 00000000`00000101 00000000`00000031 00000000`00000000 fffff880`02fd3180 : nt!KeBugCheckEx
    fffff880`03184a50 fffff800`02c856f7 : fffff880`00000000 fffff800`00000003 00000000`00002710 fffffa80`0371e2e0 : nt! ?? ::FNODOBFM::`string'+0x4e3e
    fffff880`03184ae0 fffff800`031f5895 : fffff800`0321b460 fffff880`03184c90 fffff800`0321b460 fffffa80`00000000 : nt!KeUpdateSystemTime+0x377
    fffff880`03184be0 fffff800`02c78113 : 00000000`8ebf83fc fffff800`02df6e80 00000000`02710000 00000000`00000000 : hal!HalpHpetClockInterrupt+0x8d
    fffff880`03184c10 fffff800`02c809f0 : fffff800`02df6e80 00000000`00000001 00000000`00000000 fffff880`03184e98 : nt!KiInterruptDispatchNoLock+0x163 (TrapFrame @ fffff880`03184c10)
    fffff880`03184da0 fffff800`02cbf95c : 00000000`0000000d fffff800`02df6e80 fffff8a0`002df790 00000000`00200100 : nt!KeFlushMultipleRangeTb+0x260
    fffff880`03184e70 fffff880`0126869c : fffffa80`03747040 0000000b`4c696fe4 00000000`0000000d fffff800`02df6e80 : nt!MmSetAddressRangeModified+0x2b0
    fffff880`03184f70 fffff880`01313dfb : fffff8a0`002df790 0000000b`4c696f63 00000000`00000000 00000000`00000000 : Ntfs!LfsFlushLfcb+0x5d8
    fffff880`031850f0 fffff880`01315f10 : fffff8a0`002851f0 0000000b`4c696f63 fffff880`03185550 fffff880`03185550 : Ntfs!LfsFlushToLsnPriv+0x143
    fffff880`03185180 fffff880`01264274 : fffff8a0`002851f0 0000000b`4c696f63 0000000b`4c696f63 fffff8a0`0272bb40 : Ntfs!LfsFlushToLsn+0xa0
    fffff880`031851b0 fffff880`01264e73 : fffff880`03185390 fffffa80`07a5d7a0 fffff880`03185500 00000000`00001000 : Ntfs!NtfsCommonWrite+0x2d63
    fffff880`03185360 fffff880`010debcf : fffffa80`07a5db40 fffffa80`07a5d7a0 fffffa80`044b9d30 00000000`00000000 : Ntfs!NtfsFsdWrite+0x1c3
    fffff880`031855e0 fffff880`010dd6df : fffffa80`043f08e0 fffffa80`071c8f20 fffffa80`043f0800 fffffa80`07a5d7a0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
    fffff880`03185670 fffff800`02c60ecf : fffffa80`07a5d7a0 fffff880`03185c58 fffff880`03185880 fffff800`02df6e80 : fltmgr!FltpDispatch+0xcf
    fffff880`031856d0 fffff800`02cbedbb : 00000000`00000000 fffff880`03185c58 fffffa80`01198020 00000000`00000000 : nt!IoSynchronousPageWrite+0x24f
    fffff880`03185750 fffff800`02cbd2f8 : fffff8a0`029f76c8 fffff8a0`029f76d0 fffffa80`0722cf90 fffffa80`0722cf90 : nt!MiFlushSectionInternal+0xb7b
    fffff880`03185990 fffff800`02cbc7d9 : 00000000`00056e3d 00000000`00000000 00000000`00001000 00000000`00000000 : nt!MmFlushSection+0xa4
    fffff880`03185a50 fffff800`02cc0136 : fffffa80`07046f68 00000000`00000001 fffffa80`00000001 00000000`00001000 : nt!CcFlushCache+0x5e9
    fffff880`03185b50 fffff800`02cc0af8 : fffff880`00000000 fffff880`03185c58 fffffa80`06a71220 fffff800`02e82918 : nt!CcWriteBehind+0x1c6
    fffff880`03185c00 fffff800`02c85261 : fffffa80`03740530 fffff800`02f72101 fffff800`02e82920 00000000`00000002 : nt!CcWorkerThread+0x1c8
    fffff880`03185cb0 fffff800`02f182ea : 00000000`00000000 fffffa80`03747040 00000000`00000080 fffffa80`036ec040 : nt!ExpWorkerThread+0x111
    fffff880`03185d40 fffff800`02c6c8e6 : fffff880`02f63180 fffffa80`03747040 fffff880`02f6dfc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
    fffff880`03185d80 00000000`00000000 : fffff880`03186000 fffff880`03180000 fffff880`031859e0 00000000`00000000 : nt!KxStartSystemThread+0x16
    There it is! Let's move forward:

    Code:
    0: kd> .trap fffff880`03184c10
    NOTE: The trap frame does not contain all registers.
    Some register values may be zeroed or incorrect.
    rax=0000000000000001 rbx=0000000000000000 rcx=fffff88003184de0
    rdx=fffff88003184ea0 rsi=0000000000000000 rdi=0000000000000000
    rip=fffff80002c809f0 rsp=fffff88003184da0 rbp=0000000000000001
     r8=fffff88003184ea0  r9=fffffffffffffffb r10=0000000000000008
    r11=fffff80002c8a760 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0         nv up ei ng nz na pe nc
    nt!KeFlushMultipleRangeTb+0x260:
    fffff800`02c809f0 8b8780200000    mov     eax,dword ptr [rdi+2080h] ds:00000000`00002080=????????
    Code:
    0: kd> knL
      *** Stack trace for last set context - .thread/.cxr resets it
     # Child-SP          RetAddr           Call Site
    00 fffff880`03184da0 fffff800`02cbf95c nt!KeFlushMultipleRangeTb+0x260
    01 fffff880`03184e70 fffff880`0126869c nt!MmSetAddressRangeModified+0x2b0
    02 fffff880`03184f70 fffff880`01313dfb Ntfs!LfsFlushLfcb+0x5d8
    03 fffff880`031850f0 fffff880`01315f10 Ntfs!LfsFlushToLsnPriv+0x143
    04 fffff880`03185180 fffff880`01264274 Ntfs!LfsFlushToLsn+0xa0
    05 fffff880`031851b0 fffff880`01264e73 Ntfs!NtfsCommonWrite+0x2d63
    06 fffff880`03185360 fffff880`010debcf Ntfs!NtfsFsdWrite+0x1c3
    07 fffff880`031855e0 fffff880`010dd6df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
    08 fffff880`03185670 fffff800`02c60ecf fltmgr!FltpDispatch+0xcf
    09 fffff880`031856d0 fffff800`02cbedbb nt!IoSynchronousPageWrite+0x24f
    0a fffff880`03185750 fffff800`02cbd2f8 nt!MiFlushSectionInternal+0xb7b
    0b fffff880`03185990 fffff800`02cbc7d9 nt!MmFlushSection+0xa4
    0c fffff880`03185a50 fffff800`02cc0136 nt!CcFlushCache+0x5e9
    0d fffff880`03185b50 fffff800`02cc0af8 nt!CcWriteBehind+0x1c6
    0e fffff880`03185c00 fffff800`02c85261 nt!CcWorkerThread+0x1c8
    0f fffff880`03185cb0 fffff800`02f182ea nt!ExpWorkerThread+0x111
    10 fffff880`03185d40 fffff800`02c6c8e6 nt!PspSystemThreadStartup+0x5a
    11 fffff880`03185d80 00000000`00000000 nt!KxStartSystemThread+0x16
    ^^ Here we can find the stored registers and the stack at the time of the interrupt.

    This is where we're going to do some instruction disassembling:

    Code:
    0: kd> u @rip
    nt!KeFlushMultipleRangeTb+0x260:
    fffff800`02c809f0 8b8780200000    mov     eax,dword ptr [rdi+2080h]
    fffff800`02c809f6 85c0            test    eax,eax
    fffff800`02c809f8 75e6            jne     nt!KeFlushMultipleRangeTb+0x250 (fffff800`02c809e0)
    fffff800`02c809fa e955ffffff      jmp     nt!KeFlushMultipleRangeTb+0x1c4 (fffff800`02c80954)
    fffff800`02c809ff 41f6c304        test    r11b,4
    fffff800`02c80a03 0f85d93c0500    jne     nt! ?? ::FNODOBFM::`string'+0xaaab (fffff800`02cd46e2)
    fffff800`02c80a09 41f6c306        test    r11b,6
    fffff800`02c80a0d 0f85a73d0500    jne     nt! ?? ::FNODOBFM::`string'+0xab8f (fffff800`02cd47ba)
    We can see there was a jump (jmp) that is back up in the nt!KeFlushMultipleRangeTb function.

    Let's go ahead and take the jmp location and instruction after the jump as the bound, to disassemble the loop:

    Code:
    0: kd> u fffff800`02c80954 fffff800`02c809ff
    nt!KeFlushMultipleRangeTb+0x1c4:
    fffff800`02c80954 410fb6c4        movzx   eax,r12b
    fffff800`02c80958 440f22c0        mov     cr8,rax
    fffff800`02c8095c 4c8bbc24a0000000 mov     r15,qword ptr [rsp+0A0h]
    fffff800`02c80964 4c8bb424a8000000 mov     r14,qword ptr [rsp+0A8h]
    fffff800`02c8096c 4c8ba424d8000000 mov     r12,qword ptr [rsp+0D8h]
    fffff800`02c80974 488bac24d0000000 mov     rbp,qword ptr [rsp+0D0h]
    fffff800`02c8097c 4c8bac24e0000000 mov     r13,qword ptr [rsp+0E0h]
    fffff800`02c80984 4881c4b0000000  add     rsp,0B0h
    fffff800`02c8098b 5f              pop     rdi
    fffff800`02c8098c 5e              pop     rsi
    fffff800`02c8098d 5b              pop     rbx
    fffff800`02c8098e c3              ret
    fffff800`02c8098f 8b0577262300    mov     eax,dword ptr [nt!KeNumberProcessors (fffff800`02eb300c)]
    fffff800`02c80995 3bc5            cmp     eax,ebp
    fffff800`02c80997 76a5            jbe     nt!KeFlushMultipleRangeTb+0x1ae (fffff800`02c8093e)
    fffff800`02c80999 4c8bd3          mov     r10,rbx
    fffff800`02c8099c 4c8bce          mov     r9,rsi
    fffff800`02c8099f 4d8bc2          mov     r8,r10
    fffff800`02c809a2 8bd5            mov     edx,ebp
    fffff800`02c809a4 488bcf          mov     rcx,rdi
    fffff800`02c809a7 48c744242805000000 mov   qword ptr [rsp+28h],5
    fffff800`02c809b0 4c896c2420      mov     qword ptr [rsp+20h],r13
    fffff800`02c809b5 e8b69b0100      call    nt!KiIpiSendRequest (fffff800`02c9a570)
    fffff800`02c809ba 4c8d1d9f9d0000  lea     r11,[nt!KiFlushRangeWorker (fffff800`02c8a760)]
    fffff800`02c809c1 4d85db          test    r11,r11
    fffff800`02c809c4 740a            je      nt!KeFlushMultipleRangeTb+0x240 (fffff800`02c809d0)
    fffff800`02c809c6 488d4c2440      lea     rcx,[rsp+40h]
    fffff800`02c809cb e8909d0000      call    nt!KiFlushRangeWorker (fffff800`02c8a760)
    fffff800`02c809d0 8b8780200000    mov     eax,dword ptr [rdi+2080h]
    fffff800`02c809d6 85c0            test    eax,eax
    fffff800`02c809d8 0f8476ffffff    je      nt!KeFlushMultipleRangeTb+0x1c4 (fffff800`02c80954)
    fffff800`02c809de 6690            xchg    ax,ax
    fffff800`02c809e0 ffc3            inc     ebx
    fffff800`02c809e2 851de0292300    test    dword ptr [nt!HvlLongSpinCountMask (fffff800`02eb33c8)],ebx
    fffff800`02c809e8 0f84da3c0500    je      nt! ?? ::FNODOBFM::`string'+0xaa91 (fffff800`02cd46c8)
    fffff800`02c809ee f390            pause
    fffff800`02c809f0 8b8780200000    mov     eax,dword ptr [rdi+2080h]
    fffff800`02c809f6 85c0            test    eax,eax
    fffff800`02c809f8 75e6            jne     nt!KeFlushMultipleRangeTb+0x250 (fffff800`02c809e0)
    fffff800`02c809fa e955ffffff      jmp     nt!KeFlushMultipleRangeTb+0x1c4 (fffff800`02c80954)
    fffff800`02c809ff 41f6c304        test    r11b,4
    Unfortunately, this is where my dissassembly skills as far as x64 go with this specific processor call stack. The only thing I can possibly see is that nt!KeFlushMultipleRangeTb+0x250 took the jump to stay in a loop.

    So, what's the summary so far? Processor #0 was the thread that created the bugcheck itself, and must have been interrupted by a clock interrupt in order to trigger the CLOCK_WATCHDOG_TIMEOUT bugcheck.



    Let's take a look into Processor #1's call stack like we did Processor #0:

    Code:
    1: kd> kv
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    fffff880`05e77210 fffff800`02c9b251 : 00000000`00000000 00000000`00000005 00000000`00000001 00000000`00224608 : nt!KeFlushMultipleRangeTb+0x266
    fffff880`05e772e0 fffff800`02dacb5e : 00000000`00000005 fffff880`05e77440 fffff6fd`400423e0 fffffa80`0516c000 : nt!MiFlushTbAsNeeded+0x1d1
    fffff880`05e773f0 fffff800`02c9b9b0 : 00000000`00004640 fffff800`02e0b580 00000000`00000000 00000000`00000000 : nt!MiAllocatePoolPages+0x4de
    fffff880`05e77530 fffff800`02db043e : 00000000`00000000 fffff880`00000000 00000000`00000000 00000000`00004640 : nt!ExpAllocateBigPool+0xb0
    fffff880`05e77620 fffff800`02c5bd9a : fffffa80`04198508 00000000`00000000 00000000`c2646641 00000000`000043b6 : nt!ExAllocatePoolWithTag+0x82e
    fffff880`05e77710 fffff880`02c8d750 : fffffa80`04429a80 00000000`00000000 00000000`000043b6 00000000`00000000 : nt!ExAllocatePoolWithTagPriority+0x4a
    fffff880`05e777a0 fffff880`02c9d932 : fffffa80`041986a8 fffff880`05e77ca0 fffffa80`04195010 fffffa80`041986a8 : afd!AfdGetBufferSlow+0xc0
    fffff880`05e777e0 fffff800`02f983a7 : fffffa80`076ca600 fffff880`05e77ca0 fffffa80`076ca600 fffffa80`076ca600 : afd! ?? ::GFJBLGFE::`string'+0xb73f
    fffff880`05e77a10 fffff800`02f98c06 : fffff880`05e77bf8 00000000`000015f0 00000000`00000001 00000000`08e01478 : nt!IopXxxControlFile+0x607
    fffff880`05e77b40 fffff800`02c7ae53 : fffff880`05e77ca0 fffffa80`04baeae0 fffff880`05e77bf8 fffff880`05e77c00 : nt!NtDeviceIoControlFile+0x56
    fffff880`05e77bb0 00000000`74be2e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`05e77c20)
    00000000`04caea38 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x74be2e09
    Code:
    1: kd> .trap fffff880`05e77c20
    NOTE: The trap frame does not contain all registers.
    Some register values may be zeroed or incorrect.
    rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
    rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
    rip=0000000074be2e09 rsp=0000000004caea38 rbp=00000000050ceff0
     r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
    r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0         nv up ei pl zr na po nc
    0033:00000000`74be2e09 ??              ???
    Code:
    1: kd> knL
      *** Stack trace for last set context - .thread/.cxr resets it
     # Child-SP          RetAddr           Call Site
    00 00000000`04caea38 00000000`00000000 0x74be2e09
    We can see the stack and a lot of the registers on proc #1 are zeroed.

    Code:
    1: kd> u @rip
    00000000`74be2e09 ??              ???
                ^ Memory access error in 'u @rip'
    No dice on Processor #1.



    Let's check Processor #2:


    Code:
    2: kd> kv
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    fffff880`03316840 fffff800`02c80af2 : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`000015fc : nt!KiIpiSendRequestEx+0x98
    fffff880`03316880 fffff800`02c65705 : 00000000`00000002 26500000`975c8025 fffff880`03316ba0 00000000`00000265 : nt!KeFlushMultipleRangeTb+0x362
    fffff880`03316950 fffff800`02cfcf25 : fffffa80`03d6f3f8 fffff880`00000001 00000000`00000001 fffff880`03316bb0 : nt!MiAgeWorkingSet+0x37b
    fffff880`03316b00 fffff800`02c65b06 : 00000000`000015b0 00000000`00000000 fffffa80`00000000 00000000`00000003 : nt! ?? ::FNODOBFM::`string'+0x4c7f6
    fffff880`03316b80 fffff800`02c65fb3 : 00000000`00000008 fffff880`03316c10 00000000`00000001 fffffa80`00000000 : nt!MmWorkingSetManager+0x6e
    fffff880`03316bd0 fffff800`02f182ea : fffffa80`037b7660 00000000`00000080 fffffa80`036ec040 00000000`00000001 : nt!KeBalanceSetManager+0x1c3
    fffff880`03316d40 fffff800`02c6c8e6 : fffff880`02f63180 fffffa80`037b7660 fffff880`02f6dfc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
    fffff880`03316d80 00000000`00000000 : fffff880`03317000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16
    Processor #2 appears to be trying to send an IPI using nt!KiIpiSendRequestEx. Interestingly enough, we can see that it is caught in the same function that Processor #0 is in (nt!KeFlushMultipleRangeTb). Again, this may be caused by a loop.

    Code:
    2: kd> !irql
    Debugger saved IRQL for processor 0x2 -- 0 (LOW_LEVEL)
    Either it's running at 0 or the IRQL despite saying 'saved' really didn't get saved. Windows Internals notes this is a possibility.

    Code:
    2: kd> u @rip
    nt!KiIpiSendRequestEx+0x98:
    fffff800`02c8aa08 8b8780200000    mov     eax,dword ptr [rdi+2080h]
    fffff800`02c8aa0e 85c0            test    eax,eax
    fffff800`02c8aa10 749e            je      nt!KiIpiSendRequestEx+0x40 (fffff800`02c8a9b0)
    fffff800`02c8aa12 ffc3            inc     ebx
    fffff800`02c8aa14 851dae892200    test    dword ptr [nt!HvlLongSpinCountMask (fffff800`02eb33c8)],ebx
    fffff800`02c8aa1a 0f8455cffcff    je      nt! ?? ::FNODOBFM::`string'+0x5d50 (fffff800`02c57975)
    fffff800`02c8aa20 f390            pause
    fffff800`02c8aa22 ebe4            jmp     nt!KiIpiSendRequestEx+0x98 (fffff800`02c8aa08) <--- @rip
    We can see here that it executes a pause instruction, and then tries again (most likely waiting for something to set a flag). With that said, it appears to be looping.



    Let's now take a look at the problematic proc (#3):

    Code:
    3: kd> kv
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0
    Code:
    3: kd> r
    rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
    rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
    rip=0000000000000000 rsp=0000000000000000 rbp=0000000000000000
     r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
    r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0         nv up di pl nz na pe nc
    cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000
    00000000`00000000 ??              ???
    Remember this? All zeroed out. As far as I know, this happens when either the bugcheck thread is unable to interrupt the target processor to gather the context (usually due to running at a high IRQL), OR because the processor itself is hung, therefore very little was preserved.

    Code:
    3: kd> !pcr
    KPCR for Processor 3 at fffff88002fd3000:
        Major 1 Minor 1
        NtTib.ExceptionList: fffff88002fde540
            NtTib.StackBase: fffff88002fd7f40
           NtTib.StackLimit: 0000000002cef3b8
         NtTib.SubSystemTib: fffff88002fd3000
              NtTib.Version: 0000000002fd3180
          NtTib.UserPointer: fffff88002fd37f0
              NtTib.SelfTib: 000007fffffae000
    
                    SelfPcr: 0000000000000000
                       Prcb: fffff88002fd3180
                       Irql: 0000000000000000
                        IRR: 0000000000000000
                        IDR: 0000000000000000
              InterruptMode: 0000000000000000
                        IDT: 0000000000000000
                        GDT: 0000000000000000
                        TSS: 0000000000000000
    
              CurrentThread: fffffa80077b29a0
                 NextThread: fffffa8007368b50
                 IdleThread: fffff88002fddfc0
    
                  DpcQueue:  0xfffff88002fd79e8 0xfffff80002d9ca90 [Normal] nt!PpmPerfAction
    Code:
    3: kd> !thread
    THREAD fffffa80077b29a0  Cid 16e4.1404  Teb: 000007fffffae000 Win32Thread: fffff900c1b66c20 RUNNING on processor 3
    Not impersonating
    DeviceMap                 fffff8a000008ca0
    Owning Process            fffffa8003d6f060       Image:         SearchFilterHost.exe
    Attached Process          N/A            Image:         N/A
    Wait Start TickCount      355857         Ticks: 573 (0:00:00:08.938)
    Context Switch Count      1079           IdealProcessor: 3                 LargeStack
    UserTime                  00:00:00.109
    KernelTime                00:00:00.046
    Win32 Start Address 0x00000000770cfbf0
    Stack Init fffff88008b36db0 Current fffff88008b367c0
    Base fffff88008b37000 Limit fffff88008b2f000 Call 0
    Priority 4 BasePriority 4 UnusualBoost 0 ForegroundBoost 0 IoPriority 0 PagePriority 1
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0
    At this point, you'd go ahead and run 'dps fffff88008b2f000 fffff88008b37000' to dump the raw stack, which you'd sift through to find the first symbol after the 0xffffffff entries which has a value above it that points to a location within this stack. On an x64 processor, this is unbelievably difficult (and the raw stack is also huge). I will tell you however that it contained quite a few file system calls (fltmgr and Ntfs as we described much earlier).




    With all of this said:

    - Processor #1 is waiting for a flag to be set (likely an IPI flag). It also appears to possibly be hung.

    - Processor #2 is waiting for Processors #0, #1, and/or #3 to respond to its IPI. In addition to this, it also ran at CLOCK_LEVEL (13).

    - Processor #3 has been tagged as being the cause by the bugcheck. In addition to this, its registers and call stack are zeroed (either it was permanently hung or ran at a high IRQL).




    Just from a face analysis, this looks like hardware. However, let's be sure of this:

    1. After checking the modules list, on the software side of things, everything looks fairly clean and there isn't much mention of 3rd party. However, there is something that I would recommend removing in THIS specific situation. Uninstall any and all Asus software you have as it's in most cases problematic bloatware. Just to give you an example, I see Asus PC Probe.

    Before doing so, you may want to create a Restore Point: Windows 7 - START | type create | select "Create a Restore Point"

    2. Update to the beta nVidia chipset driver from Asus' website for your motherboard - Motherboards - M3N72-D

    3. If you're still crashing after the above, I believe we may actually have a faulty processor.

    -- If we reach step #3, before skipping straight to a faulty processor, I would like to run some HDD diagnostics most likely due to the file system routines. They may be entirely unrelated, however, you always want to be sure.

    Regards,

    Patrick
    Last edited by Patrick; 02-17-2014 at 03:42 AM.

  7. #7

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Wow! Glad I could give you a challenge :) I couldn't find PC Probe in my Program list to be able to delete it, but I did update to the chipset drive and deleted Asus Cool N' Quiet app. I'm leaving for vacation tomorrow, so will update you when I get back. Thanks for your assistance!

  8. #8

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Great, I look forward to your update.

    Regards,

    Patrick

  9. #9

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    I think that updating the nvidia chipset made the difference. Since I went from XP to Win7, that would make sense. Computer was on for 11hrs after making the upgrade yesterday and NO BSODs! Thanks for your insight. I'll touch base again if there are any further issues.

  10. #10

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Well I'll be.... that's fantastic. Please keep me updated, even if you don't crash. I would appreciate it very much.

    Regards,

    Patrick

  11. #11

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Unfortunately..... Returned from vacay and had 2 BSOD within 2 hours of restarting the computer. Should I resubmit a Kernel dump or do you think this is most likely a need for a new processor?

  12. #12

    re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Let me see the Kernel, and if it's an 0x101 with consistency, I'd say it's the processor.

    Regards,

    Patrick

  13. #13

    Re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Working on uploading the most recent dump which just occurred. Here's the link - https://www.dropbox.com/s/toc2xqb6yg...27-14-1833.DMP


    Thanks,
    Chris

  14. #14

    Re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Just a quick look-through to see what's going on:

    Code:
    0: kd> ~3
    3: kd> kv
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0
    3: kd> r
    rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
    rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
    rip=0000000000000000 rsp=0000000000000000 rbp=0000000000000000
     r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
    r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0         nv up di pl nz na pe nc
    cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000
    00000000`00000000 ??              ???
    All zeroed out (problematic processor).

    Code:
    3: kd> !pcr
    KPCR for Processor 3 at fffff88002fd3000:
        Major 1 Minor 1
        NtTib.ExceptionList: fffff88002fde540
            NtTib.StackBase: fffff88002fd7f40
           NtTib.StackLimit: 00000000024cf718
         NtTib.SubSystemTib: fffff88002fd3000
              NtTib.Version: 0000000002fd3180
          NtTib.UserPointer: fffff88002fd37f0
              NtTib.SelfTib: 000007fffffd7000
    
                    SelfPcr: 0000000000000000
                       Prcb: fffff88002fd3180
                       Irql: 0000000000000000
                        IRR: 0000000000000000
                        IDR: 0000000000000000
              InterruptMode: 0000000000000000
                        IDT: 0000000000000000
                        GDT: 0000000000000000
                        TSS: 0000000000000000
    
              CurrentThread: fffffa80041607f0
                 NextThread: fffffa800460c6f0
                 IdleThread: fffff88002fddfc0
    
                  DpcQueue:  0xfffff88002fd79e8 0xfffff80002d9ea90 [Normal] nt!PpmPerfAction
    Code:
    3: kd> !thread
    THREAD fffffa80041607f0  Cid 16d8.0680  Teb: 000007fffffd7000 Win32Thread: 0000000000000000 RUNNING on processor 3
    Not impersonating
    DeviceMap                 fffff8a0018faf80
    Owning Process            fffffa800649d3d0       Image:         dllhost.exe
    Attached Process          N/A            Image:         N/A
    Wait Start TickCount      308171         Ticks: 476 (0:00:00:07.425)
    Context Switch Count      6              IdealProcessor: 2             
    UserTime                  00:00:00.000
    KernelTime                00:00:00.000
    Win32 Start Address 0x000000007795fbf0
    Stack Init fffff88007898db0 Current fffff880078987c0
    Base fffff88007899000 Limit fffff88007893000 Call 0
    Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
    Child-SP          RetAddr           : Args to Child                                                           : Call Site
    00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0
    Dump the raw stack:

    Code:
    fffff880`07897960  fffff880`01236680 Ntfs!NtfsCommonCleanupCallout
    fffff880`07897968  fffff880`07897aa0
    fffff880`07897970  00000000`00000000
    fffff880`07897978  fffffa80`076f9010
    fffff880`07897980  00000000`00000000
    fffff880`07897988  00000000`00000000
    fffff880`07897990  fffffa80`076f936b
    fffff880`07897998  fffff880`01105072 fltmgr!FltpSyncIoCompletion+0x12
    fffff880`078979a0  fffffa80`00000000
    fffff880`078979a8  fffffa80`00000000
    fffff880`078979b0  00000000`00000000
    fffff880`078979b8  00000000`00000000
    fffff880`078979c0  00000000`001c9a00
    fffff880`078979c8  fffff800`02c815d1 nt!IopfCompleteRequest+0x341
    fffff880`078979d0  fffff880`07897c00
    fffff880`078979d8  fffff800`02e06c80 nt!KiNode0+0x80
    fffff880`078979e0  fffff6fc`40055d40
    fffff880`078979e8  fffffa80`00000000
    fffff880`078979f0  00000000`00000000
    fffff880`078979f8  00000000`00000702
    fffff880`07897a00  fffff880`07897bf0
    fffff880`07897a08  00000000`0000ffff
    fffff880`07897a10  fffff8a0`107e0a90
    fffff880`07897a18  fffff880`012353cb Ntfs!NtfsCleanupIrpContext+0x12b
    fffff880`07897a20  fffff880`07897b88
    fffff880`07897a28  fffff880`07897e00
    fffff880`07897a30  00000000`00000000
    fffff880`07897a38  fffff8a0`107e0bc0
    fffff880`07897a40  fffffa80`07680430
    fffff880`07897a48  00000000`00000000
    fffff880`07897a50  fffffa80`076807d0
    fffff880`07897a58  fffff880`012b48fd Ntfs!NtfsQueryNameInfo+0x135
    fffff880`07897a60  fffff8a0`0125c2d0
    fffff880`07897a68  fffff880`012353cb Ntfs!NtfsCleanupIrpContext+0x12b
    fffff880`07897a70  fffff880`07897c80
    fffff880`07897a78  fffffa80`076f9010
    fffff880`07897a80  00000000`00000000
    fffff880`07897a88  00000000`00000000
    fffff880`07897a90  fffff880`07897c80
    fffff880`07897a98  fffff8a0`0125c2d0
    fffff880`07897aa0  fffff880`07897c80
    fffff880`07897aa8  fffff8a0`0125c1a0
    fffff880`07897ab0  fffffa80`076f9010
    fffff880`07897ab8  fffff880`0123785c Ntfs!NtfsExtendedCompleteRequestInternal+0x11c
    fffff880`07897ac0  fffff880`07897c80
    fffff880`07897ac8  fffffa80`00000001
    fffff880`07897ad0  00000000`00000000
    fffff880`07897ad8  00000000`00000000
    fffff880`07897ae0  fffffa80`076f9368
    fffff880`07897ae8  fffff880`07897c80
    fffff880`07897af0  00000000`000000fc
    fffff880`07897af8  fffff880`012b66f0 Ntfs!NtfsCommonQueryInformation+0xec8
    fffff880`07897b00  fffff8a0`0125c1a0
    fffff880`07897b08  fffff880`07897c80
    fffff880`07897b10  00000000`00000000
    fffff880`07897b18  fffff8a0`0125c200
    fffff880`07897b20  fffffa80`00000001
    fffff880`07897b28  fffff880`07897bf0
    fffff880`07897b30  fffff8a0`01a83910
    fffff880`07897b38  00000000`00000000
    fffff880`07897b40  00000000`00000101
    fffff880`07897b48  fffff8a0`0125c1a0
    fffff880`07897b50  fffffa80`07a63030
    fffff880`07897b58  fffffa80`0462c180
    fffff880`07897b60  fffff8a0`01a83910
    fffff880`07897b68  fffff8a0`0125c1a0
    fffff880`07897b70  fffffa80`0462c180
    fffff880`07897b78  fffffa80`00000000
    fffff880`07897b80  fffff8a0`0125c2d0
    fffff880`07897b88  fffff880`00000002
    fffff880`07897b90  fffff880`07897b00
    fffff880`07897b98  fffff880`0123727e Ntfs!NtfsInitializeTopLevelIrp+0x3e
    fffff880`07897ba0  fffffa80`070c4fe0
    fffff880`07897ba8  fffffa80`0450ee74
    fffff880`07897bb0  fffffa80`070c4fb0
    fffff880`07897bb8  fffff880`07897c18
    fffff880`07897bc0  fffff880`07897c80
    fffff880`07897bc8  fffffa80`076f9010
    fffff880`07897bd0  00000000`00000000
    fffff880`07897bd8  fffff880`012b44c6 Ntfs!NtfsFsdDispatchSwitch+0x2a6
    fffff880`07897be0  fffff880`07897c80
    fffff880`07897be8  fffffa80`076f9010
    fffff880`07897bf0  00000000`000000be
    fffff880`07897bf8  fffffa80`000000fc
    fffff880`07897c00  00000000`00000002
    fffff880`07897c08  fffffa80`0649d768
    fffff880`07897c10  fffff880`00000000
    fffff880`07897c18  00000000`02000001
    fffff880`07897c20  00000000`00000000
    fffff880`07897c28  00000000`00000000
    fffff880`07897c30  00000000`00000000
    fffff880`07897c38  00000000`00000000
    fffff880`07897c40  fffffa80`07a63030
    fffff880`07897c48  fffffa80`064904b0
    fffff880`07897c50  fffffa80`0462c030
    fffff880`07897c58  fffff880`012b4af4 Ntfs!NtfsFsdDispatchWait+0x14
    fffff880`07897c60  fffff880`07897c80
    fffff880`07897c68  fffffa80`076f9010
    fffff880`07897c70  fffffa80`076f9010
    fffff880`07897c78  00000000`00000000
    fffff880`07897c80  00000000`01c0070a
    fffff880`07897c88  00000000`00000001
    fffff880`07897c90  00000000`00000000
    fffff880`07897c98  00000000`00000005
    fffff880`07897ca0  00000000`00000000
    fffff880`07897ca8  00000000`00000000
    fffff880`07897cb0  fffffa80`0462c180
    fffff880`07897cb8  fffffa80`076f9010
    fffff880`07897cc0  fffff880`07897c80
    fffff880`07897cc8  fffff880`07897cc8
    fffff880`07897cd0  fffff880`07897cc8
    fffff880`07897cd8  fffff880`07897cd8
    fffff880`07897ce0  fffff880`07897cd8
    fffff880`07897ce8  00000000`00000000
    fffff880`07897cf0  00000000`00000000
    fffff880`07897cf8  00000000`00000000
    fffff880`07897d00  00000000`00000000
    fffff880`07897d08  00000000`00000000
    fffff880`07897d10  00000000`00000000
    fffff880`07897d18  00000000`00000000
    fffff880`07897d20  00000000`00000000
    fffff880`07897d28  00000000`00000000
    fffff880`07897d30  fffff880`07897d30
    fffff880`07897d38  fffff880`07897d30
    fffff880`07897d40  00000000`00000000
    fffff880`07897d48  00000000`00000000
    fffff880`07897d50  00000000`00000000
    fffff880`07897d58  00000000`00000000
    fffff880`07897d60  00000000`00000000
    fffff880`07897d68  00000000`00000000
    fffff880`07897d70  00000000`00000000
    fffff880`07897d78  00000000`00000000
    fffff880`07897d80  00000000`00000000
    fffff880`07897d88  00000000`00000000
    fffff880`07897d90  00000000`00000000
    fffff880`07897d98  00000000`00000000
    fffff880`07897da0  00000000`00000000
    fffff880`07897da8  00000000`00000000
    fffff880`07897db0  00000000`00000000
    fffff880`07897db8  00000000`00000000
    fffff880`07897dc0  00000000`00000000
    fffff880`07897dc8  00000000`00000000
    fffff880`07897dd0  00000000`00000000
    fffff880`07897dd8  fffffa80`00000001
    fffff880`07897de0  00000000`00000000
    fffff880`07897de8  fffff800`02c8eb91 nt!IopAllocateIrpPrivate+0x141
    fffff880`07897df0  fffffa80`076f9368
    fffff880`07897df8  fffff880`07897f90
    fffff880`07897e00  fffffa80`076f9010
    fffff880`07897e08  fffff800`02c8e9cc nt!IopFreeIrp+0x11c
    fffff880`07897e10  00000000`0000000a
    fffff880`07897e18  fffff880`07897f90
    fffff880`07897e20  fffffa80`070c4fe0
    fffff880`07897e28  fffffa80`070c4fb0
    fffff880`07897e30  fffffa80`07a63030
    fffff880`07897e38  fffffa80`064904b0
    fffff880`07897e40  fffffa80`076f9010
    fffff880`07897e48  fffff880`01122c75 fltmgr!FltpQueryInformationFile+0x125
    fffff880`07897e50  fffffa80`04cba8d0
    fffff880`07897e58  fffff800`02db1e80 nt!ExAllocatePoolWithTag+0x270
    fffff880`07897e60  00000000`000000fc
    fffff880`07897e68  fffff880`02f63180
    fffff880`07897e70  fffff8a0`01a83910
    fffff880`07897e78  fffff8a0`0125c1a0
    fffff880`07897e80  00000008`00000010
    fffff880`07897e88  00000002`00000005
    fffff880`07897e90  00000001`01060000
    fffff880`07897e98  fffff880`07897e98
    fffff880`07897ea0  fffff880`07897e00
    fffff880`07897ea8  00000000`00000801
    fffff880`07897eb0  fffffa80`070c4f50
    fffff880`07897eb8  6e664d46`01122af7
    fffff880`07897ec0  fffffa80`04cba8d0
    fffff880`07897ec8  00000000`00000000
    fffff880`07897ed0  fffffa80`0462c030
    fffff880`07897ed8  fffffa80`07a63030
    fffff880`07897ee0  00000000`00000009
    fffff880`07897ee8  fffff880`07897f10
    fffff880`07897ef0  fffffa80`04cba8d0
    fffff880`07897ef8  fffffa80`070c4f50
    fffff880`07897f00  00000000`00000000
    fffff880`07897f08  fffff880`011229bd fltmgr!FltpGetOpenedFileName+0x1d
    fffff880`07897f10  00000000`000000ce
    fffff880`07897f18  00000000`000000ff
    fffff880`07897f20  00000000`00000000
    fffff880`07897f28  fffffa80`002186a0
    fffff880`07897f30  fffffa80`03602030
    fffff880`07897f38  fffff800`02ca190f nt!MiRemoveAnyPage+0x24f
    fffff880`07897f40  fffff880`07897f80
    fffff880`07897f48  00000000`0000b2ce
    fffff880`07897f50  fffffa80`002186a0
    fffff880`07897f58  00000000`0000013a
    fffff880`07897f60  00000000`00000000
    fffff880`07897f68  00000000`000007ff
    fffff880`07897f70  fffffa80`04cba8d0
    fffff880`07897f78  fffff880`01122e80 fltmgr!FltpCreateFileNameInformation+0x150
    fffff880`07897f80  00000000`00000000
    fffff880`07897f88  00000002`00000001
    fffff880`07897f90  00000000`00000000
    fffff880`07897f98  00000000`00000000
    fffff880`07897fa0  00000000`00000001
    fffff880`07897fa8  fffffa80`00000000
    fffff880`07897fb0  00000000`00000000
    fffff880`07897fb8  fffffa80`03602050
    fffff880`07897fc0  fffffa80`070c4f50
    fffff880`07897fc8  00000000`00000000
    fffff880`07897fd0  fffffa80`04cba8d0
    fffff880`07897fd8  00000000`00000000
    fffff880`07897fe0  00000000`00000000
    fffff880`07897fe8  00000000`00000000
    fffff880`07897ff0  fffffa80`03800100
    fffff880`07897ff8  00000000`00000000
    fffff880`07898000  00000000`00000000
    fffff880`07898008  00000000`00000000
    fffff880`07898010  00000000`00000000
    fffff880`07898018  fffff880`07898128
    fffff880`07898020  fffffa80`04cba8d0
    fffff880`07898028  fffff880`01104c3b fltmgr!FltpFreeNameGenerationContext+0x4b
    fffff880`07898030  00000000`00000000
    fffff880`07898038  00000000`00000001
    fffff880`07898040  fffffa80`002186a0
    fffff880`07898048  00000000`00000002
    fffff880`07898050  ffffffff`ffffffff
    fffff880`07898058  fffff800`02cb26da nt!MiMapProcessMetaPage+0x2fa
    fffff880`07898060  00000000`0000b2ce
    fffff880`07898068  fffff880`078980c0
    fffff880`07898070  fffff6fb`831fdf88
    fffff880`07898078  fffff6fb`831fdf88
    fffff880`07898080  00000000`00000100
    fffff880`07898088  00000000`00000801
    fffff880`07898090  00000000`00000000
    fffff880`07898098  6e664d46`00000000
    fffff880`078980a0  00000000`00000000
    fffff880`078980a8  00000000`00000000
    fffff880`078980b0  00000000`00000001
    fffff880`078980b8  fffff800`02c93cef nt!RtlCopyUnicodeString+0x3f
    fffff880`078980c0  00000004`070c4fe0
    fffff880`078980c8  00000008`00000001
    fffff880`078980d0  fffffa80`041607f0
    fffff880`078980d8  fffffa80`070c4f50
    fffff880`078980e0  00000000`000000cd
    fffff880`078980e8  00000000`000000ff
    fffff880`078980f0  00000000`c0000034
    fffff880`078980f8  fffff880`078986c0
    fffff880`07898100  fffff8a0`0000b010
    fffff880`07898108  00000000`f8ee5494
    fffff880`07898110  fffff880`07898688
    fffff880`07898118  fffff800`02f4bb19 nt!CmpParseCacheLookup+0x21d
    Various file system related routines.

    ----------------

    Two things I want to do before calling this a faulty processor, and that's Memtest + Chkdsk + Seatools. Run Memtest for NO LESS than ~8 passes (several hours):

    Memtest86+:

    Download Memtest86+ here:

    Memtest86+ - Advanced Memory Diagnostic Tool

    Which should I download?

    You can either download the pre-compiled ISO that you would burn to a CD and then boot from the CD, or you can download the auto-installer for the USB key. What this will do is format your USB drive, make it a bootable device, and then install the necessary files. Both do the same job, it's just up to you which you choose, or which you have available (whether it's CD or USB).

    Do note that some older generation motherboards do not support USB-based booting, therefore your only option is CD (or Floppy if you really wanted to).

    How Memtest works:

    Memtest86 writes a series of test patterns to most memory addresses, reads back the data written, and compares it for errors.

    The default pass does 9 different tests, varying in access patterns and test data. A tenth test, bit fade, is selectable from the menu. It writes all memory with zeroes, then sleeps for 90 minutes before checking to see if bits have changed (perhaps because of refresh problems). This is repeated with all ones for a total time of 3 hours per pass.

    Many chipsets can report RAM speeds and timings via SPD (Serial Presence Detect) or EPP (Enhanced Performance Profiles), and some even support changing the expected memory speed. If the expected memory speed is overclocked, Memtest86 can test that memory performance is error-free with these faster settings.

    Some hardware is able to report the "PAT status" (PAT: enabled or PAT: disabled). This is a reference to Intel Performance acceleration technology; there may be BIOS settings which affect this aspect of memory timing.

    This information, if available to the program, can be displayed via a menu option.

    Any other questions, they can most likely be answered by reading this great guide here:

    FAQ : please read before posting

    -------------------------------------------------------------------------------------------------------------

    Chkdsk:

    Chkdsk:
    There are various ways to run Chkdsk~


    Method 1:

    Start > Search bar > Type cmd (right click run as admin to execute Elevated CMD)

    Elevated CMD should now be opened, type the following:

    chkdsk x: /r

    x implies your drive letter, so if your hard drive in question is letter c, it would be:

    chkdsk c: /r

    Restart system and let chkdsk run.

    Method 2:


    Open the "Computer" window
    Right-click on the drive in question
    Select the "Tools" tab
    In the Error-checking area, click <Check Now>.

    If you'd like to get a log file that contains the chkdsk results, do the following:

    Press Windows Key + R and type powershell.exe in the run box

    Paste the following command and press enter afterwards:

    get-winevent -FilterHashTable @{logname="Application"; id="1001"}| ?{$_.providername –match "wininit"} | fl timecreated, message | out-file Desktop\CHKDSKResults.txt

    This will output a .txt file on your Desktop containing the results of the chkdsk.

    If chkdsk turns out okay, run Seatools -

    SeaTools | Seagate

    You can run it via Windows or DOS. Do note that the only difference is simply the environment you're running it in. In Windows, if you are having what you believe to be device driver related issues that may cause conflicts or false positive, it may be a wise decision to choose the most minimal testing environment (DOS).

    Run all tests EXCEPT: Fix All and anything Advanced.

  15. #15

    Re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Okay, not good news because I ran all three tests and found nothing wrong. Also had several more BSODs with the same result. So this means it the processor?? Any suggestions for replacements that will work with my motherboard and Win7? Unless you have some other suggestions that might work instead?

    Thanks

  16. #16

    Re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Here is the link for the chkdskresults: https://www.dropbox.com/s/b56fu65n61...DSKResults.txt

  17. #17

    Re: BSOD secondary processor - 0x101 - Windows 7 x64 SP1

    Your Dropbox link isn't working, but if all of those diagnostics passed, this is likely a faulty processor, yes. Is it under warranty? If so, contact Intel and/or AMD (sorry, I don't have your dumps on hand right now and I cannot remember which you have) and let them know you've gone through a slew of 0x101 diagnostics, and the processor seems likely as everything else passes. In most cases, 0x101 crashes are caused by a problematic processor, but in some cases it's other things.

    If it's no longer under warranty, you'll likely want to get a processor that is of course compatible with your motherboard. Again, I don't have your dumps on hand currently so I don't know your motherboard model either.

    Regards,

    Patrick

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 tonyglock in forum BSOD, Crashes, Kernel Debugging
    Replies: 1
    Last Post: 12-28-2013, 03:36 AM
  3. 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
  4. 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
  5. 0x101 "A clock interrupt was not received on a secondary processor..."
    By oatcoatedstoat in forum BSOD, Crashes, Kernel Debugging
    Replies: 89
    Last Post: 06-08-2012, 08:49 AM

Log in

Log in