[SOLVED] Crashes alternating between BSoD and straight up freezing

C

CommuneCode

Member
Joined
Apr 26, 2014
Posts
14
· OS - Windows 7
· x64
· Win 7
· Retail Version
· ~ 2 Years Old System
· I just reinstalled my OS

· AMD A6-3670K APU
· Sapphire Radeon 6670 2GB
· ASRock A75M Fm1
· Not sure about PSU ~500 W

  • Desktop Custom Built

View attachment Code'sBSoD.zip
I have recently reinstalled my Windows 7 and it has just been very unstable, it has been alternating between locking and freezing/crashing and a BSoD labelled "A Clock interrupt was not received on a secondary processor". It makes the computer unusable after about 5-10 minutes, I have tried everything under the sun to fix it i.e swapping out memory, reinstalling the OS again, resetting BIOS, and runing numerous diagnostic tests I have come up with nothing.
 
Hi,

We're going to need a kernel-dump for this type of bug check.

Kernel-dumps are located at C:\Windows and named MEMORY.DMP. If there is nothing there, you may need to enable generation of them - Creating a Kernel-Mode Dump File (Windows Debuggers)

You will need to upload this to somewhere like Ondrive, Dropbox, etc, and then paste the link here.

Regards,

Patrick
 
Patrick said:
Hi,

We're going to need a kernel-dump for this type of bug check.

Kernel-dumps are located at C:\Windows and named MEMORY.DMP. If there is nothing there, you may need to enable generation of them - Creating a Kernel-Mode Dump File (Windows Debuggers)

You will need to upload this to somewhere like Ondrive, Dropbox, etc, and then paste the link here.

Regards,

Patrick
Click to expand...

Ok, I will see if I can get the bugger booted up long enough to grab it, thanks for the quick reply though!
 
My pleasure!

If you can't manage to stay in Windows long enough, you can do it via Safe Mode w/ Networking.

Regards,

Patrick
 
Thanks very much!

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.

So there's the basic definition of this particular bug check. Let's get into the debugging now.

Code: 
BugCheck 101, {[COLOR=#ff0000]31[/COLOR], 0, fffff880009ea180, 1}

^^ 31 clock ticks in regards to the timeout.

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

Code: 
0: kd> !prcb 1
PRCB for Processor 1 at [COLOR=#ff0000]fffff880009ea180[/COLOR]:
Current IRQL -- 0
Threads--  Current fffffa8006eb4620 Next fffffa8006d4fb50 Idle fffff880009f4fc0
Processor Index 1 Number (0, 1) GroupSetMember 2
Interrupt Count -- 00256d50
Times -- Dpc    0000000f Interrupt 0000009c 
         Kernel 0001166c User      0000339e

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 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.


Code: 
0: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`0318ba58 fffff800`02b22a4a : 00000000`00000101 00000000`00000031 00000000`00000000 fffff880`009ea180 : nt!KeBugCheckEx
fffff880`0318ba60 fffff800`02ad56f7 : fffff880`00000000 fffff800`00000001 00000000`000186a0 fffff880`0318c130 : nt! ?? ::FNODOBFM::`string'+0x4e3e
fffff880`0318baf0 fffff800`02a17895 : fffff800`02a3d460 fffff880`0318bca0 fffff800`02a3d460 fffff880`00000000 : nt!KeUpdateSystemTime+0x377
fffff880`0318bbf0 fffff800`02ac8113 : 00000000`acbbec06 fffff800`02c46e80 00000000`00000000 fffff880`0318bc60 : hal!HalpHpetClockInterrupt+0x8d
fffff880`0318bc20 fffff800`02ad09f6 : fffff800`02c46e80 00000000`00000001 00000000`00000000 fffff880`0318bea8 : nt!KiInterruptDispatchNoLock+0x163 ([COLOR=#ff0000]TrapFrame @ fffff880`0318bc20[/COLOR])
fffff880`0318bdb0 fffff800`02b0f95c : fffff880`0318c501 00000000`00000000 fffff980`11dbf000 00000000`00000000 : nt!KeFlushMultipleRangeTb+0x266
fffff880`0318be80 fffff880`0126e64d : fffffa80`03cda660 00000000`4b117ff0 fffff880`0318c501 00000000`00000000 : nt!MmSetAddressRangeModified+0x2b0
fffff880`0318bf80 fffff880`01319bb5 : fffff8a0`0014b910 00000000`4b119e3a 00000000`00000000 00000000`00000000 : Ntfs!LfsFlushLfcb+0x5ad
fffff880`0318c0f0 fffff880`0131bdf1 : fffff880`0318c550 00000000`4b119e3a fffff880`0318c550 fffff8a0`00129dc0 : Ntfs!LfsFlushToLsnPriv+0x155
fffff880`0318c180 fffff880`0126a094 : fffff8a0`00129dc0 00000000`4b119e3a 00000000`4b119e3a fffff8a0`02b44010 : Ntfs!LfsFlushToLsn+0xa1
fffff880`0318c1b0 fffff880`0126ac93 : fffff880`0318c390 fffffa80`04926810 fffff880`0318c500 00000000`0001d000 : Ntfs!NtfsCommonWrite+0x2d63
fffff880`0318c360 fffff880`0101dbcf : fffffa80`04926bb0 fffffa80`04926810 fffffa80`03eb9a90 00000000`00000000 : Ntfs!NtfsFsdWrite+0x1c3
fffff880`0318c5e0 fffff880`0101c6df : fffffa80`04bbc8e0 fffffa80`068bbf20 fffffa80`04bbc800 fffffa80`04926810 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880`0318c670 fffff800`02ab0ecf : fffffa80`04926810 fffff880`0318cc58 fffffa80`06e45cd0 fffff800`02c46e80 : fltmgr!FltpDispatch+0xcf
fffff880`0318c6d0 fffff800`02b0edbb : 00000000`00000000 fffff880`0318cc58 fffffa80`00aa8aa0 00000000`00000000 : nt!IoSynchronousPageWrite+0x24f
fffff880`0318c750 fffff800`02b0d2f8 : fffff8a0`02b54010 fffff8a0`02b540f8 fffffa80`03e35d10 fffffa80`03e35d10 : nt!MiFlushSectionInternal+0xb7b
fffff880`0318c990 fffff800`02b0c7d9 : 00000000`00014a4d 00000000`00000000 00000000`0001d000 00000000`00000000 : nt!MmFlushSection+0xa4
fffff880`0318ca50 fffff800`02b10136 : fffffa80`04179598 fffffa80`00000001 fffff800`00000001 fffffa80`0001d000 : nt!CcFlushCache+0x5e9
fffff880`0318cb50 fffff800`02b10af8 : fffff800`02cd2900 fffff880`0318cc58 fffffa80`040059f0 fffff800`02cd2918 : nt!CcWriteBehind+0x1c6
fffff880`0318cc00 fffff800`02ad5261 : fffffa80`03cec190 fffff800`02dc2101 fffff800`02cd2920 fffffa80`00000000 : nt!CcWorkerThread+0x1c8
fffff880`0318ccb0 fffff800`02d682ea : ffffffff`fffbfbff fffffa80`03cda660 00000000`00000080 fffffa80`03cb7040 : nt!ExpWorkerThread+0x111
fffff880`0318cd40 fffff800`02abc8e6 : fffff880`009ea180 fffffa80`03cda660 fffff880`009f4fc0 fffff7ff`ffffffff : nt!PspSystemThreadStartup+0x5a
fffff880`0318cd80 00000000`00000000 : fffff880`0318d000 fffff880`03187000 fffff880`0318c9e0 00000000`00000000 : nt!KxStartSystemThread+0x16

Code: 
0: kd> .trap fffff880`0318bc20
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=fffff8800318bdf0
rdx=fffff8800318beb0 rsi=0000000000000000 rdi=0000000000000000
[COLOR=#ff0000]rip=fffff80002ad09f6[/COLOR] rsp=fffff8800318bdb0 rbp=0000000000000001
 r8=fffff8800318beb0  r9=0000000000000001 r10=0000000000000000
r11=fffff80002ada760 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
[COLOR=#4b0082]nt!KeFlushMultipleRangeTb+0x266:[/COLOR]
[COLOR=#ff0000]fffff800`02ad09f6[/COLOR] 85c0            test    eax,eax

Code: 
0: kd> u @rip
nt!KeFlushMultipleRangeTb+0x266:
fffff800`02ad09f6 85c0            [COLOR=#ff0000]test    eax,eax[/COLOR] [COLOR=#4b0082]<--- Checking if value is non-zero.[/COLOR]
fffff800`02ad09f8 75e6            [COLOR=#ff0000]jne[/COLOR]     [COLOR=#ff0000]nt!KeFlushMultipleRangeTb+0x250 (fffff800`02ad09e0)[/COLOR] [COLOR=#4b0082]<--- Jump again (if not zero)[/COLOR].
fffff800`02ad09fa e955ffffff      [COLOR=#ff0000]jmp[/COLOR]     [COLOR=#ff0000]nt!KeFlushMultipleRangeTb+0x1c4 (fffff800`02ad0954)[/COLOR] [COLOR=#4b0082]<--- Jump.[/COLOR]
fffff800`02ad09ff 41f6c304        test    r11b,4
fffff800`02ad0a03 0f85d93c0500    jne     nt! ?? ::FNODOBFM::`string'+0xaaab (fffff800`02b246e2)
fffff800`02ad0a09 41f6c306        test    r11b,6
fffff800`02ad0a0d 0f85a73d0500    jne     nt! ?? ::FNODOBFM::`string'+0xab8f (fffff800`02b247ba)
fffff800`02ad0a13 85ff            test    edi,edi

Code: 
0: kd> u fffff800`02ad09e0 fffff800`02ad09fa
nt!KeFlushMultipleRangeTb+0x250:
fffff800`02ad09e0 ffc3            inc     ebx
fffff800`02ad09e2 851de0292300    test    dword ptr [nt!HvlLongSpinCountMask (fffff800`02d033c8)],ebx
fffff800`02ad09e8 0f84da3c0500    je      nt! ?? ::FNODOBFM::`string'+0xaa91 (fffff800`02b246c8)
fffff800`02ad09ee f390            [COLOR=#ff0000]pause[/COLOR]
fffff800`02ad09f0 8b8780200000    mov     eax,dword ptr [rdi+2080h]
fffff800`02ad09f6 85c0            test    eax,eax
fffff800`02ad09f8 75e6            jne     nt!KeFlushMultipleRangeTb+0x250 (fffff800`02ad09e0)
fffff800`02ad09fa e955ffffff      jmp     nt!KeFlushMultipleRangeTb+0x1c4 (fffff800`02ad0954)

It appears at the time of the bug check, the thread was executing a pause (a CPU delay), and doing this in a loop waiting for a release.


Code: 
1: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0

Code: 
1: 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 ??              ???

^^ On the problematic processor, we have a zerod stack + registers, so this will be problematic. Usually this occurs on the problem processor because the IRQL is too high, OR the processor was too hung at the time of the crash to report its information, etc. We will need to get the raw stack.

Code: 
1: kd> !thread
THREAD fffffa8006eb4620  Cid 082c.0edc  Teb: 000007fffffde000 Win32Thread: fffff900c1abec20 RUNNING on processor 1
Not impersonating
DeviceMap                 fffff8a000008e00
Owning Process            fffffa8006eb4b30       Image:         mscorsvw.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      84544          Ticks: 473 (0:00:00:07.378)
Context Switch Count      5788           IdealProcessor: 3                 LargeStack
UserTime                  00:00:05.116
KernelTime                00:00:00.436
Win32 Start Address 0x000000013f342420
Stack Init fffff88005c39db0 Current fffff88005c39aa0
Base [COLOR=#006400]fffff88005c3a000 [/COLOR]Limit [COLOR=#000080]fffff88005c32000 [/COLOR]Call 0
Priority 6 BasePriority 6 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

Code: 
fffff880`05c37d48  fffff880`01304e49 [COLOR=#ff0000]Ntfs!LfsWriteLogRecordIntoLogPage+0x329[/COLOR]
fffff880`05c37d50  00000000`0000001c
fffff880`05c37de0  fffffa80`03cb7040
fffff880`05c37de8  fffff880`0130bea4 [COLOR=#ff0000]Ntfs!LfsWrite+0x404[/COLOR]
fffff880`05c37df0  fffffa80`06938100
fffff880`05c37df8  fffff880`05c37ff0
fffff880`05c37e00  00000000`00000000
fffff880`05c37e08  fffffa80`06938100
fffff880`05c37e10  00000000`00000001
fffff880`05c37e18  fffff880`05c38c44
fffff880`05c37e20  00000000`4b10a2b1
fffff880`05c37e28  00000000`4b10a2b1
fffff880`05c37e30  00000000`00000060
fffff880`05c37e38  00000000`00000000
fffff880`05c37e40  fffff880`05c37f70
fffff880`05c37e48  00000000`00000000
fffff880`05c37e50  00000000`00000000
fffff880`05c37e58  fffffa80`0422b010
fffff880`05c37e60  00000000`00000000
fffff880`05c37e68  00000000`00000000
fffff880`05c37e70  fffff8a0`080c64f0
fffff880`05c37e78  fffff880`05c38c30
fffff880`05c37e80  fffff8a0`01bc0bc0
fffff880`05c37e88  fffff880`05c38c30
fffff880`05c37e90  fffff880`05c38040
fffff880`05c37e98  fffff8a0`080c6078
fffff880`05c37ea0  fffffa80`03cb7040
fffff880`05c37ea8  fffff880`01307ef4 Ntfs!NtfsWriteLog+0xe22
fffff880`05c38040  fffffa80`03cb7040
fffff880`05c38048  fffff800`02adf1b0 nt!CcUnpinFileDataEx+0x120
fffff880`05c38050  fffffa80`0422b010
fffff880`05c380b8  00000000`00000000
fffff880`05c380c0  fffffa80`0422b010
fffff880`05c380c8  fffff800`02dc8ad1 nt!CcUnpinData+0x41
fffff880`05c380d0  ffff0000`04e98ebb
fffff880`05c380f0  fffff980`0719c000
fffff880`05c380f8  fffff880`013141e3 Ntfs!NtfsUpdateFileNameInIndex+0x63e
fffff880`05c38100  00000000`00000000
fffff880`05c38300  fffff8a0`080c6010
fffff880`05c38308  fffff880`01312b71 Ntfs!NtfsUpdateFileNameInParent+0x5d0
fffff880`05c38310  fffff880`05c38c30
fffff880`05c38460  ffff0000`04e9731b
fffff880`05c38468  fffff800`02adf1b0 nt!CcUnpinFileDataEx+0x120
fffff880`05c38498  00000000`00000000
fffff880`05c384a0  fffff880`00c161a0 ataport!WPP_MAIN_CB
fffff880`05c384a8  00000000`00000001
fffff880`05c384b0  fffff800`02ad5aa5 nt!KiIpiInterrupt+0x135
fffff880`05c384b8  fffff880`05c38408
fffff880`05c384d8  fffffa80`04a821b0
fffff880`05c384e0  fffff800`02ad5aa5 nt!KiIpiInterrupt+0x135
fffff880`05c384e8  00001f80`00c30a38
fffff880`05c38580  fffff880`05c385f0
fffff880`05c38588  fffff880`00c0f5ad ataport!IdeProcessPortNotification+0x16d
fffff880`05c38590  00000000`0000f050
fffff880`05c385c8  fffff880`00c05fd8 ataport!AtaPortGetPhysicalAddress+0x2c
fffff880`05c385d0  00000000`0000f050
fffff880`05c385d8  00000000`00000008
fffff880`05c38628  fffff880`00c05dbe ataport!AtaPortWritePortUchar+0x6
fffff880`05c38630  00000000`00000010
fffff880`05c38638  fffff880`00e5d6d4 atapi!AtapiSetupPrdTable+0xf4
fffff880`05c38640  fffff880`05c38658
fffff880`05c38648  00000000`00000000
fffff880`05c38650  fffff880`05c386c8
fffff880`05c38658  fffff880`00e5d5c9 atapi!AtapiProgramTaskFile+0x75
fffff880`05c38660  fffffa80`03c271a0
fffff880`05c38668  fffff880`00c161a0 ataport!WPP_MAIN_CB
fffff880`05c38670  00000000`00000001
fffff880`05c38678  fffffa80`04a821b0
fffff880`05c38680  fffffa80`03c286a8
fffff880`05c38688  fffff880`00e5d17a atapi!AtapiSendAtaCommand+0x15e
fffff880`05c38690  fffffa80`069e3f68
fffff880`05c386b0  00000003`00000000
fffff880`05c386b8  fffff880`00e5d01c atapi!AtapiSendAtaCommand
fffff880`05c386c0  fffffa80`069e3fb0
fffff880`05c386c8  00000000`00000000
fffff880`05c386d0  fffffa80`03c271a0
fffff880`05c386d8  fffff880`00c161a0 ataport!WPP_MAIN_CB
fffff880`05c386f8  fffff880`00e5cee1 atapi!AtapiHandleAtaCommand+0x45
fffff880`05c38700  00000000`00000050
fffff880`05c38720  fffffa80`03c286a8
fffff880`05c38728  fffff880`00e5c656 atapi!AtapiHwStartIo+0x66
fffff880`05c38730  fffffa80`069e3f68
fffff880`05c38750  fffffa80`069e3b80
fffff880`05c38758  fffff880`00c0bf6b ataport!IdeStartCrbSynchronized+0x7b
fffff880`05c38760  00000000`0000003c
fffff880`05c387c0  00000000`00000001
fffff880`05c387c8  fffff800`02ac7476 nt!KeSynchronizeExecution+0x46
fffff880`05c387d0  00000000`0000003c
fffff880`05c387d8  fffff880`00c01c74 ataport!IdeLogCrbActive+0xe0
fffff880`05c387e0  fffffa80`04a70db0
fffff880`05c38800  fffffa80`069e3b80
fffff880`05c38808  fffff880`00c0bec6 ataport!IdeStartIoCallBack+0x2ea
fffff880`05c38810  fffffa80`069e3d10
fffff880`05c38830  00000000`00100021
fffff880`05c38838  fffff800`02add4b8 nt!SeAccessCheckWithHint+0x178
fffff880`05c38850  00000000`00007000
fffff880`05c38858  fffff800`02a0f524 hal!HalpDmaMapScatterTransfer+0x34
fffff880`05c388a0  00000000`00000000
fffff880`05c388a8  fffff800`02a124fb hal!HalpMapTransfer+0x7b
fffff880`05c388b0  fffffa80`069e3d10
fffff880`05c38930  fffffa80`067728d0
fffff880`05c38938  fffff800`02a12472 hal!IoMapTransfer+0x8e
fffff880`05c38940  fffffa80`069e3d10
fffff880`05c38970  00000000`00000000
fffff880`05c38978  fffff800`02a119ce hal!HalpAllocateAdapterCallback+0x146
fffff880`05c38980  fffffa80`069e3c50
fffff880`05c38988  00000000`00008000
fffff880`05c38990  00000000`00000000
fffff880`05c38998  fffff800`02b7e264 nt!KeRemoveDeviceQueue+0x94
fffff880`05c389a0  fffffa80`069e3d10
fffff880`05c389c8  fffffa80`04a7ff68
fffff880`05c389d0  fffff880`00e3212c PCIIDEX!BmReceiveScatterGatherList
fffff880`05c389d8  00000000`00008000
fffff880`05c389e0  00000000`00000008
fffff880`05c389e8  fffff800`02a11a56 hal!IoFreeAdapterChannel+0x62
fffff880`05c389f0  fffffa80`04a7fea0
fffff880`05c38a10  fffffa80`069e3c50
fffff880`05c38a18  fffff800`02a12156 hal!HalAllocateAdapterChannel+0x11a
fffff880`05c38a50  00000000`00000000
fffff880`05c38a58  fffff800`02a1171f hal!HalBuildScatterGatherList+0x2f3
fffff880`05c38a60  fffffa80`069e3c20
fffff880`05c38a98  fffff800`02a1142c hal!HalBuildScatterGatherList
fffff880`05c38aa0  fffff880`00c161a0 ataport!WPP_MAIN_CB
fffff880`05c38aa8  00000000`00000002
fffff880`05c38ac0  fffffa80`03c27100
fffff880`05c38ac8  fffff880`00e320d3 [COLOR=#ff0000]PCIIDEX!BmSetup+0x6b[/COLOR]
fffff880`05c38ad0  fffffa80`069e3b80
fffff880`05c38ad8  fffff880`00e3212c [COLOR=#ff0000]PCIIDEX!BmReceiveScatterGatherList[/COLOR]
fffff880`05c38ae0  fffffa80`00000100
fffff880`05c38ae8  fffff880`00000000
fffff880`05c38af0  00000000`00008000
fffff880`05c38af8  fffff880`00e3212c [COLOR=#ff0000]PCIIDEX!BmReceiveScatterGatherList[/COLOR]

^^ PCIIDEX indicates that there were calls to the PCI IDE Bus. Do you have an IDE HDD, or RAID card, or anything PCI relating to a drive? It looks like we crash whilst the drive is writing to the JFS (journaling file system) via LFS (Log File Service).



Code: 
2: kd> k
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0x0

Code: 
2: 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 ??              ???

Processor #2 is also zeroed out, not good!

Code: 
3: kd> k
Child-SP          RetAddr           Call Site
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 ??              ???

Processor #3 also.



I have never seen so many zeroed out cores on a processor before, not very good at all. I almost want to say straight away that this is a faulty processor, but I am of course going to do my best to try and see otherwise.

1. I already asked above, but I'll put it here as well just in case you miss it among the information.

Do you have an IDE HDD, or RAID card, or anything PCI relating to a drive? It looks like we crash whilst the drive is writing to the JFS (journaling file system) via LFS (Log File Service).

If the answer is yes, disconnect whatever it is just so long as it's not the OS drive (of course). Please also uninstall whatever software may have been included.

2. AODDriver2.sys is listed and loaded in your modules list which is AMD Overdrive; also in EasyTune6 for Gigabyte motherboard. Known BSOD issues in Win7 & 8.

Please uninstall either software ASAP! If you cannot find either software to uninstall, or it's not installed, please navigate to the following filepath:

C:\Program Files\ATI Technologies\ATI.ACE\Fuel\amd64\AODDriver2.sys

and rename AODDriver2.sys to AODDriver.2old

and then Restart.

Regards,

Patrick
 
Ok, to your first worry about my processor, my dad said that it might be also, and if so, you are right, NOT good.

To your first question, no I do not have anything PCI related to storage but when the problem arose I was seeing if the problem was my hard drive so I changed a BIOS setting that said something like the way my hard drive was loaded, I tried switching it to RAID mode but then Windows wouldn't load at all so I switched it back. But even after that I reset BIOS twice and held the power button in for 30 seconds about 4 times (not sure what that does, my dad told me to do it). But the motherboard thing is weird because I don't have a Gigabyte Motherboard, mine is ASRock, so that is weird in its' own.

To your second solution, I kind of thought it might have been my graphics card, but after the problem started happening I wrote zeros to my drive and installed Windows again, just to see if the screen locking up happened after a fresh install, but it did. So maybe my drivers I installed are outdated? I guess I will try to rename that Overdrive file like you said and report back!
 
Last edited:
Well, sorry about that, misinformation. It got rid of the blue screens but not the constant crashes, it was fine on the desktop for over an hour but playing a game for about 15-25 minutes it just crashed, happened twice on two different games that ran fine before I reinstalled Windows
 
Can you please attach the latest crash dumps from after renaming the AODDriver2.sys?

Regards,

Patrick
 
Whenever I play a game it just freezes and locks up my screen, I have tried letting it sit and see if it unfreezes but it doesn't, it behaves like it is about to blue screen but never gets to the actual blue screen itself.
 
Thanks, I appreciate it.

Can you please run a Memtest for me 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


If Memtest shows no errors after ~8 passes, is it possible for you to remove your current HDD and install a secondary HDD for testing to install Windows on? If you still crash with a fresh Windows on a secondary HDD, this is a faulty processor.

Regards,

Patrick
 
I could take the HDD out of my laptop and run it, and I did run a memtest at first but not 8 passes, I'll try and report back.
 
Well, unfortunately I ran the test 12 passes and nothing, so much for playing my PC any time soon! I will send for the processor warranty.
 
I can not afford that, I don't have a free HDD laying around or else I would, I have too much stuff on my laptop's HDD to lose to try and wipe it for something that may not work.
 
Understood.

Well, in any case, if you get the CPU back from RMA and the problem persists, it's likely a HDD fault. Keep me updated.

Regards,

Patrick
 
Back
Top