Solved Stability issues. FX-6300 and . Frequent Freezes

[H0lyD1ver]

Hello,
I've got a machine that I think the only issue preventing stability are the BIOS settings. The machine will not run Prime95 without errors, and as soon as I bumped the voltage to the CPU it seemed to be more stable. I haven't really had BSOD's to analyze. I've got several logs from running Prime95 at various settings. The most stable I've gotten it (fewer errors, longest run time) is to run Prime95 for 24+ hours by dropping the RAM bus clock speed to like 400MHz (from 667)

Has anybody else had issues with machines not running at stock/default settings?

Attached are the reports from the Log Collector and a few Prime95 logs (named after the BIOS settings or cpu voltage).

Any help/suggestions would be appreciated! I've been spending the past few weeks running tests and pulling out my hair.

Below are the hardware specs:
OS: Windows 7 Pro 64-bit
Case + PSU: RAIDMAX Super Hurricane ATX-248BP Black Steel / Plastic ATX Mid Tower Computer Case 450W Power Supply
Motherboard: ASRock 960GM/U3S3 FX AM3+ AMD 760G + SB710 SATA 6Gb/s USB 3.0 Micro ATX AMD Motherboard
CPU: AMD FX-6300 Vishera 3.5GHz (4.1GHz Turbo) Socket AM3+ 95W Desktop Processor FD6300WMHKBOX
RAM: CORSAIR 4GB 240-Pin DDR3 SDRAM DDR3 1333 Desktop Memory Model CMV4GX3M1A1333C9
Hard Drive: Western Digital WD Blue WD5000AAKX 500GB 7200 RPM 16MB Cache SATA 6.0Gb/s 3.5" Internal Hard Drive Bare Drive - OEM
Disk Drive: LG Internal Super Multi Drive SATA Model GH24NSB0 - OEM

 

[H0lyD1ver]

Update: I'm running Memtest 86+ again and this time I've so far encounter one error and I'm at 5 passes...could that be the culprit?

 

[Mellon Head]

Could be the problem there. What is your RAM voltage set to?

 

[H0lyD1ver]

Love your avatar!

I've tried various settings, including 1.6 and 9-9-9-24, 2T, but I still get errors from Prime95. Is there a good way to narrow down the ideal voltages, or just trial and error?

 

[Mellon Head]

The ideal voltage is no more than 1.5 volts. I would relax the timings to something like 10-10-10-30 and see if you can get it to be stable with Prime95. Once it's stable, we can experiment with tightening up the timings a little bit.

Some motherboards simply don't like running the memory at the advertised timings. I have one like that. I can't run 2 4GB sticks together at their advertised timings, but I can run 4 2GB sticks at tighter timings. Same brand of RAM, and I don't know why there's a difference, but like me, your mobo might be part of the problem.

Another thing. You shouldn't normally have to raise your core voltage to run the CPU stable at stock (or turbo) speeds. I think the problem in this case is memory related. Especially if you are getting errors with Memtest86+.

 

[H0lyD1ver]

Thanks for the help. I think you may be on to something with the ram speed and compatible ram. In my previous torture tests, when I dropped the ram down to like 400mhz or whatever it ran solid. I'll keep you guys posted with my progress.

 

[Indianatone]

Just for giggles what is the brand of the power supply? A crappy no name brand can cause instability issues. Download HWMonitor from CPUID website and give us a screenshot of the voltages (and temps for that matter). Version 1.25 is the newest.

HWMonitor CPUID - System & hardware benchmark, monitoring, reporting

 

[H0lyD1ver]

I'll take a screenshot from CPU-ID tomorrow, but it's a PSU that came with the case:

RAIDMAX::Super Hurricane

 

[H0lyD1ver]

Image 1 is normal conditions.
Image 2 is under Prime95.

 

[Indianatone]

I can't see anything wrong with those readings. Can you take a screenshot of the voltages and temps in your bios and if you have a camera the label on the side of the Power supply. Post back your findings.

 

[H0lyD1ver]

Alright - I reloaded the machine with a different motherboard and it still crashed/froze so I know it's not the motherboard.
I ran Driver Verifier this morning and upon first boot got a BSOD. Here is the Windbg analysis of the dump. This is after a fresh reload with a few basic programs. Does this shed any light?

3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000000000001f0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002cda325, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002f0d100
GetUlongFromAddress: unable to read from fffff80002f0d1c0
00000000000001f0 Nonpaged pool

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeSetEvent+1e3
fffff800`02cda325 488b00 mov rax,qword ptr [rax]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

BUGCHECK_STR: 0xA

PROCESS_NAME: System

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

TRAP_FRAME: fffff88003316950 -- (.trap 0xfffff88003316950)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000000001f0 rbx=0000000000000000 rcx=fffff880026f2210
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002cda325 rsp=fffff88003316ae0 rbp=0000000000000000
r8=0000000000000000 r9=fffff88002fd7180 r10=00000000000001f0
r11=fffff80002e8d480 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe cy
nt!KeSetEvent+0x1e3:
fffff800`02cda325 488b00 mov rax,qword ptr [rax] ds:00000000`000001f0=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002cd5169 to fffff80002cd5bc0

STACK_TEXT:
fffff880`03316808 fffff800`02cd5169 : 00000000`0000000a 00000000`000001f0 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`03316810 fffff800`02cd3de0 : 00000000`00000160 00000000`00000000 00000000`0000000d fffff880`026f2208 : nt!KiBugCheckDispatch+0x69
fffff880`03316950 fffff800`02cda325 : fffffa80`061a1402 fffffa80`061a1410 00000000`00000000 fffff980`14816ea0 : nt!KiPageFault+0x260
fffff880`03316ae0 fffff880`069aa817 : fffff880`00000000 fffff980`00000008 fffff800`02e83d00 fffffa80`06b6ca70 : nt!KeSetEvent+0x1e3
fffff880`03316b50 fffff880`00000000 : fffff980`00000008 fffff800`02e83d00 fffffa80`06b6ca70 fffffa80`061a1410 : MBfilt64+0x1817
fffff880`03316b58 fffff980`00000008 : fffff800`02e83d00 fffffa80`06b6ca70 fffffa80`061a1410 fffff800`0317d3fb : 0xfffff880`00000000
fffff880`03316b60 fffff800`02e83d00 : fffffa80`06b6ca70 fffffa80`061a1410 fffff800`0317d3fb fffffa80`061a1410 : 0xfffff980`00000008
fffff880`03316b68 fffffa80`06b6ca70 : fffffa80`061a1410 fffff800`0317d3fb fffffa80`061a1410 fffffa80`061a1410 : nt!ViPendingWorkers
fffff880`03316b70 fffffa80`061a1410 : fffff800`0317d3fb fffffa80`061a1410 fffffa80`061a1410 fffff980`14817000 : 0xfffffa80`06b6ca70
fffff880`03316b78 fffff800`0317d3fb : fffffa80`061a1410 fffffa80`061a1410 fffff980`14817000 fffff980`14816ea0 : 0xfffffa80`061a1410
fffff880`03316b80 fffff800`0317d47c : fffff800`02e83d60 00000000`00000080 fffffa80`036649e0 00000000`00000100 : nt!ViPendingCompleteAfterWait+0x7b
fffff880`03316bc0 fffff800`02f7173a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!ViPendingWorkerThread+0x2c
fffff880`03316c00 fffff800`02cc68e6 : fffff800`02e50e80 fffffa80`036f0040 fffff800`02e5ecc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03316c40 00000000`00000000 : fffff880`03317000 fffff880`03311000 fffff880`033168d0 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND: kb

FOLLOWUP_IP:
MBfilt64+1817
fffff880`069aa817 ?? ???

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: MBfilt64+1817

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: MBfilt64

IMAGE_NAME: MBfilt64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a7267b0

FAILURE_BUCKET_ID: X64_0xA_VRF_MBfilt64+1817

BUCKET_ID: X64_0xA_VRF_MBfilt64+1817

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:x64_0xa_vrf_mbfilt64+1817

FAILURE_ID_HASH: {3414a0c9-f17d-f07d-746a-a89ad9b168e6}

Followup: MachineOwner

 

[H0lyD1ver]

I put in faster RAM and it stopped the crashes.

 

[Indianatone]

Well glad you got it sorted. What kind of RAM did you get?

 

[H0lyD1ver]

G.SKILL 4GB (2 x 2GB) 240-Pin DDR3 SDRAM DDR3 1600 (PC3 12800) Dual Channel Kit Desktop Memory Model F3-12800CL9D-4GBNQ


G.SKILL 4GB (2 x 2GB) 240-Pin DDR3 SDRAM DDR3 1600 (PC3 12800) Dual Channel Kit Desktop Memory Model F3-12800CL9D-4GBNQ - Newegg.com

 

[H0lyD1ver]

I am happy to report that I found the problem causing all of my stability issues - we had AVG 2012 and as soon as we updated our server/clients to AVG 2013 - the crashes stopped!

Thank you for all your help and time!