Bsod after some cca. 30 mins in high load - Windows 7 x64

R

redivider

Member
Joined
Jun 21, 2014
Posts
6
I have been starting to get BSODs when doing something that puts strain onto the cpu, it is an i7 3960x engineering sample and It could be the source of the problem, but im not sure thats why im asking for help here.
The error is " Clock interrupt was not received on a secondary processor"

specs:
Win7 ultimate 64bit
cpu: i7 3960x (ES)
gpu: asus gtx 670
psu: corsair 700W
mobo: intel dx79si
8gigs corsair ram (4channel)

I did some memtests both inside the OS and outside and getting no errors.
I am also attaching some reports (minidump and perfmon)

Thanks in advance!
 

Attachments

Code: 
BugCheck 101, {21, 0, fffff880009b3180, 4}

To analyse 0x101 bugchecks we need Kernel Memory Dumps.

Go to Start
Right click on My Computer then click properties
On the left side click Advanced system settings
Under the Advanced tab click on Settings in the Startup and Recovery section
Under System failure set the Write debugging information as Kernel memory dump.
Then restart your computer.

Wait for another BSOD, once one has appeared check in this directory:

Code: 
C:/Windows/memory.dmp

Copy the dump file to the desktop then upload it to a file sharing site like Onedrive as it's too big to upload directly.
 
Sorry I've been busy regarding college and part time job interviews.

This is a strange one given that some figures are letters rather than numbers.

Code: 
BugCheck 101, {[COLOR=#ff0000]11[/COLOR], 0, [COLOR=#008000]fffff880032c9180[/COLOR], [COLOR=#0000ff]a[/COLOR]}
It might be due to the fact that you have a six core CPU with hyperthreading giving it 12 threads and C in Hexadecimal is 12 and A is 10 so it looks like the faulty thread is #10.

Anyway lets begin.

Well a clock interrupt is a synchronization mechanism that lets the processors stay in sync to improve performance, when it's sent out all the processors have to respond within the allocated time interval which in this case is 11 clock ticks.


The third parameter is the address that contains processor information of the hung processor.
The fourth parameter is mostly the processor that was responsible for not responding as I have highlighted which is A.

Lets look at Processor #0 (primary core)

Code: 
0: kd> [COLOR=#008000]kv[/COLOR]
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`0dd9b918 fffff800`02f24a4a : 00000000`00000101 00000000`00000011 00000000`00000000 fffff880`032c9180 : nt!KeBugCheckEx
fffff880`0dd9b920 fffff800`02ed76f7 : 42a9a7ce`00000000 fffff800`0000000a 00000000`00002711 c11024dc`7eec6a68 : nt! ?? ::FNODOBFM::`string'+0x4e3e
fffff880`0dd9b9b0 fffff800`02e19895 : fffff800`02e3f460 fffff880`0dd9bb60 fffff800`02e3f460 fffff800`00000000 : nt!KeUpdateSystemTime+0x377
fffff880`0dd9bab0 fffff800`02eca113 : 00000000`43c02b00 fffff880`0dd9bb01 00000000`43c6d600 00000000`00000000 : hal!HalpHpetClockInterrupt+0x8d
fffff880`0dd9bae0 00000001`41a6b4ad : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiInterruptDispatchNoLock+0x163 ([COLOR=#008000]TrapFrame @ fffff880`0dd9bae0[/COLOR])
00000000`046ce1e0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00000001`41a6b4ad

Code: 
0: kd> [COLOR=#008000].trap fffff880`0dd9bae0[/COLOR]
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000005 rbx=0000000000000000 rcx=00000000886e4200
rdx=0000000043c4b880 rsi=0000000000000000 rdi=0000000000000000
rip=0000000141a6b4ad rsp=00000000046ce1e0 rbp=0000000088897b00
 r8=00000000046ce400  r9=0000000000000800 r10=0000000000000000
r11=000000004377d000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
0033:00000001`41a6b4ad ??              ???

Code: 
0: kd> [COLOR=#008000]u @rip[/COLOR]
00000001`41a6b4ad ??              ???
[COLOR=#ff0000]            ^ Memory access error in 'u @rip'[/COLOR]

We cannot access the rip register so unfortunately we can't do any disassembling.

Lets look at processor #1

Code: 
1: kd> [COLOR=#008000]kv[/COLOR]
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`0b4354a0 fffff800`02e714a9 : 00000000`00000014 fffff880`0b9d3000 00000000`00000000 fffff880`0b9d30f4 : [COLOR=#ff8c00]nt!KeFlushMultipleRangeTb+0x260[/COLOR]
fffff880`0b435570 fffff800`02e71bc3 : fffff880`0b9d30f4 00000000`00000004 00000000`00000001 00000000`00000001 : [COLOR=#0000ff]nt!MiRemoveIoSpaceMap+0xe9[/COLOR]
fffff880`0b4356a0 fffff880`0a8787ba : 00000000`02e1fe10 fffff880`0b435b60 fffffa80`08e45dc0 00000000`00000004 : [COLOR=#0000ff]nt!MmUnmapIoSpace+0x83[/COLOR]
fffff880`0b4356f0 fffff800`031eae67 : fffffa80`08742ba0 fffffa80`0932e720 fffffa80`0932e838 fffffa80`0932e720 : [COLOR=#ff0000]cpuz136_x64+0x17ba[/COLOR]
fffff880`0b4358d0 fffff800`031eb6c6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x607
fffff880`0b435a00 fffff800`02ecce53 : fffff880`0b435b60 fffffa80`09a0dac0 fffff880`0b435ab8 00000000`02e1fe00 : nt!NtDeviceIoControlFile+0x56
fffff880`0b435a70 00000000`76e3132a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0b435ae0)
00000000`02e1fc58 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76e3132a

I've actually encountered an issue with an OP previously where CPUZ has actually caused a problem but it might have been a one off.
It looks like it's removing the mapping from the physical address to non paged system space.

This is followed by a nt!KeFlushMultipleRangeTb+0x260 This is a method of flushing the TranslationLookasideBuffers and allow them to be rebuilt which should help the problematic processor execute handler instructions and any future instructions otherwise Windows bugchecks. If the processor isn't synced properly it will flush the TLB and hopefully it will be able to get through all the work it was behind with so the system doesn't bugcheck.

Lets look at processor #2
Code: 
[/COLOR]2: kd> [COLOR=#008000]kv[/COLOR]
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`09eab1a0 fffff800`02ed2af2 : 00000000`00000000 00000000`00000001 00000000`00000000 007f0100`007f0100 : [COLOR=#0000ff]nt!KiIpiSendRequestEx+0x9e[/COLOR]
fffff880`09eab1e0 fffff800`02eed251 : 00000000`00000000 ffffffff`ffffffff 00000000`00000001 00000000`00000111 : [COLOR=#ff8c00]nt!KeFlushMultipleRangeTb+0x362[/COLOR]
fffff880`09eab2b0 fffff800`02eefc98 : 00000000`00000018 fffff880`09eab400 fffff900`c312d000 fffff880`03089180 : [COLOR=#ff8c00]nt!MiFlushTbAsNeeded+0x1d1[/COLOR]
fffff880`09eab3c0 fffff800`02ffef86 : 00000000`00018000 fffff880`025fecc0 00000000`00000021 00000000`00000000 : [COLOR=#800080]nt!MiAllocatePagedPoolPages+0x4cc[/COLOR]
fffff880`09eab4e0 fffff800`02eed9b0 : 00000000`00018000 fffff880`025fecc0 00000000`00000021 fffff960`000dfaad : [COLOR=#800080]nt!MiAllocatePoolPages+0x906[/COLOR]
fffff880`09eab620 fffff800`0300243e : 00000000`00000000 fffff880`02f6a140 fffffa80`00000020 00000000`00017f80 : [COLOR=#800080]nt!ExpAllocateBigPool+0xb0[/COLOR]
fffff880`09eab710 fffff960`00174c91 : fffffa80`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : [COLOR=#800080]nt!ExAllocatePoolWithTag+0x82e[/COLOR]
fffff880`09eab800 fffff960`0017634a : fffff880`09eab8c0 fffff880`09eab9a0 fffff960`0027771b 00000000`00000001 : win32k!AllocateObject+0xdd
fffff880`09eab840 fffff960`0014d064 : fffff900`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : win32k!SURFMEM::bCreateDIB+0x38a
fffff880`09eab930 fffff960`0014cbde : 00000050`00000131 00000000`00000050 00000000`01080030 00000000`00000131 : win32k!hsurfCreateCompatibleSurface+0x3bc
fffff880`09eaba00 fffff800`02ecce53 : fffffa80`087d3640 fffff880`09eabb60 00000000`00000000 fffff900`c00c0010 : win32k!GreCreateCompatibleBitmap+0x26e
fffff880`09eabae0 00000000`748a2e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`09eabae0)
00000000`03d7eb38 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x748a2e09[COLOR=#000000]
There are some pool allocation routines followed by the Inter-Processor Interrupt which is the routine to flush all TLBs.
Let's look at the status of the IPIs sent out.

Code: 
[/COLOR][COLOR=#ff0000]IPI State for Processor 10[/COLOR]
[COLOR=#ff0000]
[/COLOR]
[COLOR=#ff0000]    As a receiver, unhandled requests are pending from processor(s) 1, 2, 3, 4, 7, 9.[/COLOR]


    TargetCount          0  PacketBarrier        0  IpiFrozen     5 [Target Freeze]


    From processor 1, active request of type: flush multiple range
        Flush Count 1  Flush List fffff8800b4355c8  (dp fffff8800b4355c8 l1)
    From processor 2, active request of type: flush process
    From processor 3, active request of type: flush multiple range
        Flush Count 1  Flush List fffff8800ac124a8  (dp fffff8800ac124a8 l1)
    From processor 4, active request of type: flush multiple range
        Flush Count 1  Flush List fffff8800351d098  (dp fffff8800351d098 l1)
    From processor 7, active request of type: packet ready
        WorkerRoutine fffff80002ebee10 (nt!xHalReportIdleStateUsage)
        Parameter[0] 0  Parameter[1] 0  Parameter[2] 0
    From processor 9, active request of type: packet ready
        WorkerRoutine fffff80002ebee10 (nt!xHalReportIdleStateUsage)
        Parameter[0] 0  Parameter[1] 0  Parameter[2] 0


[COLOR=#ff0000]IPI State for Processor 11[/COLOR]
[COLOR=#ff0000]
[/COLOR]
[COLOR=#ff0000]    As a receiver, unhandled requests are pending from processor(s) 1, 2, 3, 4, 7, 9.[/COLOR]


    TargetCount          0  PacketBarrier        0  IpiFrozen     5 [Target Freeze]


    From processor 1, active request of type: flush multiple range
        Flush Count 1  Flush List fffff8800b4355c8  (dp fffff8800b4355c8 l1)
    From processor 2, active request of type: flush process
    From processor 3, active request of type: flush multiple range
        Flush Count 1  Flush List fffff8800ac124a8  (dp fffff8800ac124a8 l1)
    From processor 4, active request of type: flush multiple range
        Flush Count 1  Flush List fffff8800351d098  (dp fffff8800351d098 l1)
    From processor 7, active request of type: packet ready
        WorkerRoutine fffff80002ebee10 (nt!xHalReportIdleStateUsage)
        Parameter[0] 0  Parameter[1] 0  Parameter[2] 0
    From processor 9, active request of type: packet ready
        WorkerRoutine fffff80002ebee10 (nt!xHalReportIdleStateUsage)
        Parameter[0] 0  Parameter[1] 0  Parameter[2] 0[COLOR=#000000]

Processors #10 and 11 are really far behind which makes me believe this is a hardware problem.

Lets look at Processor #3

Code: 
[/COLOR]3: kd> [COLOR=#008000]kv[/COLOR]
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`0ac123a0 fffff800`02eed251 : 00000000`00000000 00000000`00000008 00000000`00000001 fffff800`00000001 : [COLOR=#ff8c00]nt!KeFlushMultipleRangeTb+0x260[/COLOR]
fffff880`0ac12470 fffff800`02eefc98 : 00000000`00000008 fffff880`0ac125c0 fffff8a0`0c224000 00000000`00000001 : [COLOR=#ff8c00]nt!MiFlushTbAsNeeded+0x1d1[/COLOR]
fffff880`0ac12580 fffff800`02ffef86 : 00000000`00008000 fffffa80`06691000 00000000`00000009 fffff800`02ed0a8a : [COLOR=#800080]nt!MiAllocatePagedPoolPages+0x4cc[/COLOR]
fffff880`0ac126a0 fffff800`02eed9b0 : 00000000`00008000 fffffa80`06691000 00000000`00000009 20206553`02ec35f2 : [COLOR=#800080]nt!MiAllocatePoolPages+0x906[/COLOR]
fffff880`0ac127e0 fffff800`0300243e : 00000000`00000000 fffffa80`082c6a80 00000000`00000000 00000000`00008000 : [COLOR=#800080]nt!ExpAllocateBigPool+0xb0[/COLOR]
fffff880`0ac128d0 fffff800`02ee0f56 : fffffa80`066922b0 00000000`00000009 fffff8a0`01b18060 fffff800`031b9c5f : [COLOR=#800080]nt!ExAllocatePoolWithTag+0x82e[/COLOR]
fffff880`0ac129c0 fffff800`03139f86 : 00000000`00000000 00000000`00008000 00000000`00000000 00000000`00000001 : [COLOR=#800080]nt!ExAllocatePoolWithQuotaTag+0x56[/COLOR]
fffff880`0ac12a10 fffff800`03191b94 : fffff8a0`0bfa4a80 fffff800`00008000 fffff880`0ac12b01 fffff800`0339bda0 : [COLOR=#0000ff]nt!PiControlGetInterfaceDeviceList+0x92[/COLOR]
fffff880`0ac12a90 fffff800`02ecce53 : fffffa80`082f0060 00000000`0067ea90 fffff880`0ac12b60 00000000`0067eb18 : [COLOR=#0000ff]nt!NtPlugPlayControl+0x100[/COLOR]
fffff880`0ac12ae0 00000000`76e3230a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0ac12ae0)
00000000`0067ea58 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76e3230a[COLOR=#000000]

This processor appears to be looking at Plug and Play devices then allocating memory for them until the flush TLB IPI is sent out.

Lets move onto Processor #4

Code: 
[/COLOR]4: kd> [COLOR=#008000]kv[/COLOR]
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`0351cfa0 fffff800`02f1195c : fffff800`03073201 2073664c`00000000 fffff980`1b3b5000 fffff880`012fbe49 : [COLOR=#ff8c00]nt!KeFlushMultipleRangeTb+0x266[/COLOR]
fffff880`0351d070 fffff880`0126564d : fffffa80`0673f040 00000010`d136eaa0 fffff800`03073201 2073664c`00000000 : [COLOR=#800080]nt!MmSetAddressRangeModified+0x2b0[/COLOR]
fffff880`0351d170 fffff880`01310bb5 : fffff8a0`001c9290 00000010`d136ebef 00000000`00000001 00000000`00000700 : [COLOR=#800080]Ntfs!LfsFlushLfcb+0x5ad[/COLOR]
fffff880`0351d2e0 fffff880`01313269 : fffff800`03073280 00000010`d136ebef fffff800`03073280 fffff8a0`001c9290 : [COLOR=#800080]Ntfs!LfsFlushToLsnPriv+0x155[/COLOR]
fffff880`0351d370 fffff880`0131072a : fffff8a0`001c9290 fffff8a0`001d0b80 fffff8a0`00377050 fffff8a0`001c9290 : [COLOR=#800080]Ntfs!LfsWriteLfsRestart+0xf9[/COLOR]
fffff880`0351d3b0 fffff880`0130f07f : fffff8a0`001d0b80 00000000`00000000 00000010`d1365a29 fffffa80`07117438 : [COLOR=#800080]Ntfs!LfsWriteRestartArea+0x13a[/COLOR]
fffff880`0351d440 fffff880`0131254e : fffff880`0351d970 fffffa80`07117180 00000000`00000000 fffff880`01265c00 : [COLOR=#800080]Ntfs!NtfsCheckpointVolume+0xab0[/COLOR]
fffff880`0351d850 fffff880`01310e12 : fffff880`0351d970 fffffa80`07117188 fffff880`0351d970 fffff880`012589c0 : [COLOR=#800080]Ntfs!NtfsCheckpointAllVolumesWorker+0x4e[/COLOR]
fffff880`0351d8a0 fffff880`0131302e : fffff880`0351d970 fffff800`03073280 fffff880`01312500 fffff880`0351db78 : [COLOR=#800080]Ntfs!NtfsForEachVcb+0x172[/COLOR]
fffff880`0351d940 fffff800`02ed7261 : fffff880`01312f70 fffff800`031c4c00 fffffa80`0673f000 fffffa80`00000003 : [COLOR=#800080]Ntfs!NtfsCheckpointAllVolumes+0xbe[/COLOR]
fffff880`0351db70 fffff800`0316973a : 00000000`00000000 fffffa80`0673f040 00000000`00000080 fffffa80`0669f890 : nt!ExpWorkerThread+0x111
fffff880`0351dc00 fffff800`02ebe8e6 : fffff880`0333b180 fffffa80`0673f040 fffff880`033461c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`0351dc40 00000000`00000000 : fffff880`0351e000 fffff880`03518000 fffff880`0351d8a0 00000000`00000000 : nt!KxStartSystemThread+0x16[COLOR=#000000]

These appear to be some NTFS write routines which are undocumented so I can't find too much on them, then it's interrupted due to the flush TLB IPI.

Lets move on to Processor #5

Code: 
[/COLOR]00000000`04dce600 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : [COLOR=#ff0000]0x00000001`40155eb8[/COLOR][COLOR=#000000]

There appears to be a strange string in this callstack which doesn't help much.

Lets look at Processor #6
Code: 
[/COLOR]
00000000`0f4de620 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : [COLOR=#ff0000]0x00000001`41a6c398[/COLOR][COLOR=#000000]

It appears to be similar but not identical which again doesn't help.

Lets look at Processor #7

Code: 
[/COLOR]7: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`092e9530 fffff800`03189bdf : 00000000`00000000 fffff880`092e9b60 00000000`00000000 00000000`00000000 : [COLOR=#ff8c00]nt!KeFlushProcessWriteBuffers+0x65[/COLOR]
fffff880`092e95a0 fffff800`031d9416 : 00000000`00333780 fffffa80`00010400 fffff880`092e9730 00000000`00000000 : [COLOR=#0000ff]nt!ExpGetProcessInformation+0x7f[/COLOR]
fffff880`092e96f0 fffff800`031d9e6d : 00000000`00333780 00000000`00000000 00000000`00000005 00000000`00aee7a0 : [COLOR=#0000ff]nt!ExpQuerySystemInformation+0xfb4[/COLOR]
fffff880`092e9aa0 fffff800`02ecce53 : fffffa80`08648230 00000000`00000198 00000000`00000000 fffffa80`07e8aae0 : [COLOR=#0000ff]nt!NtQuerySystemInformation+0x4d[/COLOR]
fffff880`092e9ae0 00000000`76e3161a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`092e9ae0)
00000000`00aee708 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76e3161a


[COLOR=#000000]

Just looks like the system is trying to look up properties of a certain process, followed by a flushing of a the processor write buffers.

Lets look at Processor #8

Code: 
[/COLOR]00000000`19cee728 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : [COLOR=#ff0000]0x00000001`421e5fc9[/COLOR][COLOR=#000000]

Again another string function.

Lets move on to Processor #9

Code: 
[/COLOR]9: kd> [COLOR=#008000]kv[/COLOR]
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`0dc26f90 fffff800`03189bdf : 00000000`00000000 fffff880`0dc275c0 00000000`00000000 00000000`00001f80 : [COLOR=#ff8c00]nt!KeFlushProcessWriteBuffers+0x6b[/COLOR]
fffff880`0dc27000 fffff800`031d9416 : fffff8a0`0c22c0a8 00000000`0001ff58 fffff880`0dc27190 00000000`00000000 : nt!ExpGetProcessInformation+0x7f
fffff880`0dc27150 fffff800`031d9e6d : fffff8a0`0c22c0a8 fffffa80`6365734b 00000000`00000000 fffff880`0dc27ae0 : nt!ExpQuerySystemInformation+0xfb4
fffff880`0dc27500 fffff800`02ecce53 : fffff880`0dc275d0 fffff800`02ecbdfd 00000000`00000001 fffff8a0`0c22c000 : nt!NtQuerySystemInformation+0x4d
fffff880`0dc27540 fffff800`02ec9410 : fffff880`0148e1dc fffffa80`06e4c1a0 fffff880`0dc27704 fffffa80`06e6b900 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0dc27540)
fffff880`0dc276d8 fffff880`0148e1dc : fffffa80`06e4c1a0 fffff880`0dc27704 fffffa80`06e6b900 fffff880`0112c81f : nt!KiServiceLinkage
fffff880`0dc276e0 fffff880`0148e73d : fffffa80`06e98ab0 fffff880`00e413b7 00000000`20206f49 0000000e`00000028 : [COLOR=#800080]cng!GatherRandomKey+0x22c[/COLOR]
fffff880`0dc27aa0 fffff800`031c4cad : 00000000`00000001 00000000`00000001 fffffa80`0739b550 fffffa80`097c0b50 : [COLOR=#800080]cng!scavengingWorkItemRoutine+0x3d[/COLOR]
fffff880`0dc27b40 fffff800`02ed7261 : fffff800`030732d8 fffff800`031c4c01 fffffa80`097c0b00 00000000`00000000 : nt!IopProcessWorkItem+0x3d
fffff880`0dc27b70 fffff800`0316973a : 00000000`13584c35 fffffa80`097c0b50 00000000`00000080 fffffa80`0669f890 : nt!ExpWorkerThread+0x111
fffff880`0dc27c00 fffff800`02ebe8e6 : fffff880`03257180 fffffa80`097c0b50 fffffa80`090adb50 fffff880`0e1a0390 : nt!PspSystemThreadStartup+0x5a
fffff880`0dc27c40 00000000`00000000 : fffff880`0dc28000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16[COLOR=#000000]

cng routines are encrypted APIs which are mainly used for security reasons.
The rest are query process routines which are trying to get process information (self explanatory) followed by the flushing of Processor Write Buffers.

Lets look at Processor #10 (problematic processor A)

Code: 
[/COLOR][COLOR=#ff0000]00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0[/COLOR][COLOR=#000000]

The callstack is zeroed out which is usually caused by the IRQL being too high or the processor was too hung to record information.

Lets look at the registers

Code: 
[/COLOR]10: kd> [COLOR=#008000]r[/COLOR]
[COLOR=#ff0000]rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000[/COLOR]
[COLOR=#ff0000]rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000[/COLOR]
[COLOR=#ff0000]rip=0000000000000000 rsp=0000000000000000 rbp=0000000000000000[/COLOR]
[COLOR=#ff0000] r8=0000000000000000  r9=0000000000000000 r10=0000000000000000[/COLOR]
[COLOR=#ff0000]r11=0000000000000000 r12=0000000000000000 r13=0000000000000000[/COLOR]
[COLOR=#ff0000]r14=0000000000000000 r15=0000000000000000[/COLOR]
[COLOR=#ff0000]iopl=0         nv up di pl nz na pe nc[/COLOR]
[COLOR=#ff0000]cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000[/COLOR]
[COLOR=#ff0000]00000000`00000000 ??              ???[/COLOR][COLOR=#000000]

Again all zeroed which isn't good at all.

Lets finally move onto Processor #11
Code: 
[/COLOR][COLOR=#ff0000]00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0[/COLOR]

Again this callstack is zeroed.

Code: 
11: kd> [COLOR=#008000]r[/COLOR]
[COLOR=#ff0000]rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000[/COLOR]
[COLOR=#ff0000]rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000[/COLOR]
[COLOR=#ff0000]rip=0000000000000000 rsp=0000000000000000 rbp=0000000000000000[/COLOR]
[COLOR=#ff0000] r8=0000000000000000  r9=0000000000000000 r10=0000000000000000[/COLOR]
[COLOR=#ff0000]r11=0000000000000000 r12=0000000000000000 r13=0000000000000000[/COLOR]
[COLOR=#ff0000]r14=0000000000000000 r15=0000000000000000[/COLOR]
[COLOR=#ff0000]iopl=0         nv up di pl nz na pe nc[/COLOR]
[COLOR=#ff0000]cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000[/COLOR]
[COLOR=#ff0000]00000000`00000000 ??              ???[/COLOR]

As are the registers, looking back at the IPI information we could see Processors #10 and #11 were far behind on their requests.


With all this said I think it's best that we RMA your CPU if it has warranty as it certainly looks faulty.
 
Well, thanks for the help man, appreciate it! Also, I wish you good luck in college and future endeavours. Very Informative analysis!
For now, the problem went away by pumping the voltage to 1.35V, since the CPU is overclocked.

As far as the RMA is concerned, lets just say I know some people and got the CPU as a gift, thats why its also ES, so I probably wont be returning it but wow, I learned quite a bit, especially after searching on some of the topics connected with your post.
One question: could it be that overloading the proccesor causes some cores to be left behind or something?Oor that the 10 and 12 are actually the virtual ones? Ill try messing around without HT and see what ahppens.
 
Well it could be, the more pressure you put on the CPU the more it can fail.

Check to see if it's overheating.

Take out the CMOS battery to restore any improper timings.

You shouldn't overclock when getting BSODs, reset it to factory voltage.
 
Hmmmm, It isnt overheating since it is on water cooling but there is a problem with the factory voltage. That is; the factory voltage is set to "default", which means it "configures" its own voltage as needed but the problem is that voltage shows as 1.6V at idle (obviously going down as more power is needed) on CPU-Z. I am aware that software doesnt show the correct voltage but it could not possibly be that high right? So I set it to quite a bit lower, because it seems more healthy to me then running 1.6V 24/7 no?

Ill will try getting someone to check the pc but everyone I know is on vacation currently :(
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top