RAM issues, compatability? Don't think so...

Okay so, as my profile says... I have an i7 2600k, EVGA p67ftw, and Corsair CMZ16GX3M4X1600C9. I have been BSoDing since I built it and the dumps were mainly driver related so I gave up and formatted the SSD and put a clean genuine copy of win7 ultimate64... And it's still blueing. The most recent sop codes were memory_corrupt but after all of about 98 windows updates the stops are labeled unknown even with the sdk debugger set to MS' symbol database. After some BIOS fiddling and realizing the FTW defaults to 999-24 @ 1333mhz I changed it around do the correct speed and timing to 999-27 (as specs suggest) and still bsod after bsod.. Uptime of around 15min so long as there is no load being processed by torture tests. Currently I'm overnighting memtest87 to double check that it is the ram and I will update in the morning. But what I need to know is if there is something im missing. The only thing I've touched is the timing and the multiplier. After restores in win7 and triple checking seating of everything it persists with the bsods. I would love to get it stable and OC the Ram/CPU but I won't do anything with this machine until the bsods are fixed.

update, 4hrs on memtest, 2 passes 0 errors. I went back into bios and turned off Legacy and started a new memtest. Letting it run until I wake up then I'll update again.

Have you checked for a BIOS update for your MB? If there is one please flash to the latest version, Then load set-up defaults and enable XMP. Re-run your tests.

 

Have you tried using the XMP profile instead of changing the timings manually. It usually sets memory controller voltage as well as the timings. That may be what you are missing.

 

I would also try setting the DIMM voltage to 1.55v instead of 1.5v. That may help too.

 

But so far with your memtest coming up clean, it's not pointing towards bad RAM.

Thanks for the info peanutz! I'm 99.9999% sure the bios is up to date (I'll have to double check to be sure) and when I used the xmp profiles they weren't changing anything.

What do you mean the XMP profile wasn't changing anything? Do you mean the settings, or the BSOD? If it's the settings, re you sure your saving the changes before exiting the BIOS?

 

Did you try a slight bump in voltage as suggested?

Okay, update. 9hrs 30min on memtest: 4pass, 5 errors.

 

Failing address: 00303507334 good: dfe4f30e bad: dfe5f30e

 

This was with bios manually set to rams default speeds.

Okay, set everything the way you guys insisted... still BSoD. Thinking it might be more than just the ram issue now.

 

pasting dump in case anyone wants to look...

 

Microsoft ® Windows Debugger Version 6.12.0002.633 AMD64

Copyright © Microsoft Corporation. All rights reserved.

 

 

Loading Dump File [C:\Windows\Minidump\091712-8673-01.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

 

Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 7601.17835.amd64fre.win7sp1_gdr.120503-2030

Machine Name:

Kernel base = 0xfffff800`03450000 PsLoadedModuleList = 0xfffff800`03694670

Debug session time: Mon Sep 17 14:44:05.792 2012 (UTC - 4:00)

System Uptime: 0 days 0:07:43.620

Loading Kernel Symbols

...............................................................

................................................................

....................

Loading User Symbols

Loading unloaded module list

.......

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

 

Use !analyze -v to get detailed debugging information.

 

BugCheck A, {fffff80000b8ca58, f, 1, fffff800034b857b}

 

Unable to load image xhcdrv.sys, Win32 error 0n2

*** WARNING: Unable to verify timestamp for xhcdrv.sys

*** ERROR: Module load completed but symbols could not be loaded for xhcdrv.sys

Probably caused by : memory_corruption

 

Followup: memory_corruption

---------

 

0: 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: fffff80000b8ca58, memory referenced

Arg2: 000000000000000f, IRQL

Arg3: 0000000000000001, 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: fffff800034b857b, address which referenced memory

 

Debugging Details:

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

 

 

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800036fe100

fffff80000b8ca58

 

CURRENT_IRQL: f

 

FAULTING_IP:

nt!KeInsertQueueDpc+4b

fffff800`034b857b 898c24a800ffff mov dword ptr [rsp-0FF58h],ecx

 

CUSTOMER_CRASH_COUNT: 1

 

DEFAULT_BUCKET_ID: CODE_CORRUPTION

 

BUGCHECK_STR: 0xA

 

PROCESS_NAME: System

 

TRAP_FRAME: fffff80000b9c820 -- (.trap 0xfffff80000b9c820)

NOTE: The trap frame does not contain all registers.

Some register values may be zeroed or incorrect.

rax=000000000000000f rbx=0000000000000000 rcx=0000000000000000

rdx=fffffa800da0da90 rsi=0000000000000000 rdi=0000000000000000

rip=fffff800034b857b rsp=fffff80000b9c9b0 rbp=fffffa800da0db20

r8=0000000000000000 r9=0000000000000000 r10=fffffa800da0da90

r11=0000000000000000 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0 nv up ei ng nz na po cy

nt!KeInsertQueueDpc+0x4b:

fffff800`034b857b 898c24a800ffff mov dword ptr [rsp-0FF58h],ecx ss:0018:fffff800`00b8ca58=????????

Resetting default scope

 

LAST_CONTROL_TRANSFER: from fffff800034ce769 to fffff800034cf1c0

 

STACK_TEXT:

fffff800`00b9c6d8 fffff800`034ce769 : 00000000`0000000a fffff800`00b8ca58 00000000`0000000f 00000000`00000001 : nt!KeBugCheckEx

fffff800`00b9c6e0 fffff800`034cd3e0 : fffffa80`0e865c02 fffffa80`0e76c410 fffffa80`0e865cc0 fffff800`03641e80 : nt!KiBugCheckDispatch+0x69

fffff800`00b9c820 fffff800`034b857b : 00000000`000000c1 00000000`00000017 00000000`00000000 fffffa80`00040004 : nt!KiPageFault+0x260

fffff800`00b9c9b0 fffff880`00ef8168 : fffffa80`0da40000 fffffa80`0da0da90 00000000`00000000 fffffa80`0cd7a9e0 : nt!KeInsertQueueDpc+0x4b

fffff800`00b9ca40 fffff880`0fddc46e : fffffa80`0da0da90 fffff800`00b9cb30 00000000`00000000 fffffa80`0cf7bb50 : Wdf01000!imp_WdfInterruptQueueDpcForIsr+0x94

fffff800`00b9ca80 fffffa80`0da0da90 : fffff800`00b9cb30 00000000`00000000 fffffa80`0cf7bb50 fffff800`03641e80 : xhcdrv+0x1a46e

fffff800`00b9ca88 fffff800`00b9cb30 : 00000000`00000000 fffffa80`0cf7bb50 fffff800`03641e80 fffff800`034cb01c : 0xfffffa80`0da0da90

fffff800`00b9ca90 00000000`00000000 : fffffa80`0cf7bb50 fffff800`03641e80 fffff800`034cb01c fffff800`03641e80 : 0xfffff800`00b9cb30

 

 

STACK_COMMAND: kb

 

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt

fffff800034b8580-fffff800034b85bf 64 bytes - nt!KeInsertQueueDpc+50

[ 00 00 80 7d 00 18 48 89:ff ff ff ff ff ff ff ff ]

fffff800034b8ac0-fffff800034b8ae2 35 bytes - nt!MiAgeWorkingSet+160 (+0x540)

[ 00 00 8b 54 24 30 44 8b:ff ff ff ff ff ff ff ff ]

fffff800034b8ae4-fffff800034b8aff 28 bytes - nt!MiAgeWorkingSet+184 (+0x24)

[ c7 44 24 60 00 00 00 00:00 41 8b 76 24 44 89 84 ]

127 errors : !nt (fffff800034b8580-fffff800034b8aff)

 

MODULE_NAME: memory_corruption

 

IMAGE_NAME: memory_corruption

 

FOLLOWUP_NAME: memory_corruption

 

DEBUG_FLR_IMAGE_TIMESTAMP: 0

 

MEMORY_CORRUPTOR: LARGE

 

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

 

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

 

Followup: memory_corruption

---------

 

No no that was just the debugger I ran after the last bsod. Before when I said the 5 errors in 4 passes was from memtest86. I'll try running each stick one by one and hopefully I can find out which is bad.

 

A for the driver issues (I know this is a ram forum but it can't hurt to ask) what can I use to find out exactly which drivers are not good?

which of the tests in Memtest did the error happen? and does it happen in the same test/register?

which of the tests in Memtest did the error happen? and does it happen in the same test/register?

 

From the picture I took of the screen it looks like this in red:

TST- 8 PASS-1 FAIL ADDRESS-00303507334 - 12341.0mb then GOOD/BAD ERR BITS-00010000 Count-1

12 GB? Did you test one stick at a time in the same slot? That will help you to find out if it's a stick, slot, or CPU issue.

I doing it now, how many passes per stick should I do? The first one is just about done with pass #2

3 passes should be enough.

Thanks, I'll update when it's all finished.

On stick 3 now, so far stick 1 did 3 passes no errors, and stick 2 did over 2 passes 0 errors.

Alright folks, all 4 sicks made it through 2 passes each one by one. So I'm assuming the next step is to test 1 and 3, than 2 and 4, than 1,2,3 than 1,2,3,4 to test the slots?

All 4 sticks passing in the same slot means that the sticks (and that slot) are fine. Next would be to test one stick in the other 3 slots.

I left sticks in 1 and 3 overnight (mainly because I fell asleep and forgot) but 11 passes 0 errors. So I guess the RAM isn't the problem.

 

RAM GUY: I manually set the voltage to 1550mV yesterday but the voltage readout in the bios fluctuates sound 1.489V. Is there something else I have to change to make it go higher?

I would try it at 1.575 or 1.6 Volts it is not uncommon from what I have seen some Mb's have a tendency to under volt the memory. That is why I suggested trying to up the voltage .05 Volts.

 

Turns out it was a bad SLI bridge. Running stable and prepping for 4.6+ overclock on the cpu tomorrow.

 

Thanks for the help anyway guys, I definitely learned a lot from this regardless.