Random BSODs and applications crashes on a fresh Win7 install

Scannow finished with the following message:

Windows resource protection did not find any integrity violations

Code:

Loading Dump File [E:\BSODDmpFiles\R4ndom\Windows_NT6_BSOD_jcgriff2\012812-16926-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\Users\Mike\Documents*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.17730.amd64fre.win7sp1_gdr.111123-1510
Machine Name:
Kernel base = 0xfffff800`02e0b000 PsLoadedModuleList = 0xfffff800`0304f650
Debug session time: Sat Jan 28 05:52:01.992 2012 (GMT-7)
System Uptime: 0 days 0:06:49.552
Loading Kernel Symbols
...............................................................
................................................................
.......................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {ffffffffc0000005, fffff800031627c0, 0, 2000}

Probably caused by : memory_corruption ( nt!MiPerformFixups+80 )

Followup: MachineOwner
---------

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

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff800031627c0, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000002000, Parameter 1 of the exception

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


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP: 
nt!MiPerformFixups+80
fffff800`031627c0 410fb603        movzx   eax,byte ptr [r11]

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  0000000000002000

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800030b9100
 0000000000002000 

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x1E

PROCESS_NAME:  svchost.exe

CURRENT_IRQL:  0

TRAP_FRAME:  fffff88008f5bee0 -- (.trap 0xfffff88008f5bee0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff8a0081fa000 rbx=0000000000000000 rcx=fffff8800398b000
rdx=0000000000000ff8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800031627c0 rsp=fffff88008f5c070 rbp=0000000000002001
 r8=0000000000000ffc  r9=0000000000000fff r10=fffff8800398b000
r11=0000000000002000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
nt!MiPerformFixups+0x80:
fffff800`031627c0 410fb603        movzx   eax,byte ptr [r11] ds:00000000`00002000=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002ed28e8 to fffff80002e87c80

STACK_TEXT:  
fffff880`08f5b658 fffff800`02ed28e8 : 00000000`0000001e ffffffff`c0000005 fffff800`031627c0 00000000`00000000 : nt!KeBugCheckEx
fffff880`08f5b660 fffff800`02e87302 : fffff880`08f5be38 fffff880`0398b000 fffff880`08f5bee0 ffffffff`fffb0000 : nt! ?? ::FNODOBFM::`string'+0x48d2d
fffff880`08f5bd00 fffff800`02e85e7a : 00000000`00000000 00000000`00002000 00000000`00000000 fffff880`0398b000 : nt!KiExceptionDispatch+0xc2
fffff880`08f5bee0 fffff800`031627c0 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`00166fe0 : nt!KiPageFault+0x23a
fffff880`08f5c070 fffff800`0315e947 : fffffa80`00000000 00000000`00000000 00000000`00000000 fffff8a0`081fa000 : nt!MiPerformFixups+0x80
fffff880`08f5c0d0 fffff800`02e68b92 : fffffa80`034b7410 00000000`00000000 fffffa80`00166fe0 fffff8a0`07627d68 : nt!MiRelocateImagePfn+0xf7
fffff880`08f5c130 fffff800`03162a21 : fffffa80`03d8ee30 fffff6fc`4001cc50 fffff8a0`00000002 00000000`00000000 : nt!MiValidateImagePages+0x362
fffff880`08f5c1e0 fffff800`03162b60 : ffffffff`ffffffff 00000000`00000001 fffff8a0`081fa000 00000000`00000005 : nt!MiSwitchBaseAddress+0x61
fffff880`08f5c210 fffff800`0318373f : 00000000`00000004 00000000`00000080 00000000`01000000 00000000`01000000 : nt!MiRelocateImageAgain+0x100
fffff880`08f5c260 fffff800`031622a6 : fffff880`08f5c4b0 fffff880`08f5c700 fffff880`08f5c558 fffff880`08f5c4a8 : nt!MmCreateSection+0x2df
fffff880`08f5c460 fffff800`032e3bd3 : 00000000`00000000 fffff8a0`086f2ba0 00000000`00000000 00000000`00000001 : nt!NtCreateSection+0x171
fffff880`08f5c4e0 fffff800`032e4161 : 00000000`00000000 fffff8a0`086f2ba0 fffffa80`05344220 fffff880`00000060 : nt!PfpFileBuildReadSupport+0x163
fffff880`08f5c5d0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!PfpPrefetchFilesTrickle+0x121


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiPerformFixups+80
fffff800`031627c0 410fb603        movzx   eax,byte ptr [r11]

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  nt!MiPerformFixups+80

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4ecdc9f2

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0x1E_nt!MiPerformFixups+80

BUCKET_ID:  X64_0x1E_nt!MiPerformFixups+80

Followup: MachineOwner
---------

This is likely a problem with the memory or a driver. An underlying driver may be incompatible\conflicting with your system. Run Driver Verifier to find any issues. To run Driver Verifier, do the following:

a. Backup your system and user files
b. Create a system restore point
c. If you do not have a Windows 7 DVD, Create a system repair disc
d. Run Driver Verifier

If Windows cannot start in normal mode with driver verifier running, start in safe mode. If it cannot start in safe mode or normal mode, restore the system restore point using System Restore OPTION TWO.

Thanks to zigzag3143 for contributing to the Verifier steps.
If you are unable to start Windows with all drivers being verified or if the blue screen crashes fail to create .dmp files, run them in groups of 5 or 10 until you find a group that causes blue screen crashes and stores the blue screen .dmp files.

Dave76 said:

The CPUZ info looks good.

Can you get these voltages from your BIOS?
Go to your BIOS and tell us what the CPU, RAM and the CPU integrated memory controller voltages are.
The CPU integrated memory controller voltage is CPU VTT.

These may need adjusting.

writhziden, Good idea to run Driver Verifier, it will identify any questionable drivers.

Thanks for answering Dave and writhziden.

As for CPU voltages, BIOS doesn't indicate the current voltage, as it is set on "auto" and "according to CPU", so I would guess it's running @ stock voltage for FX-4100.
Idem for CPU integrated memory controller, as it's set to auto, I don't know what's the current voltage. I would need to change them manually to know the voltage - any ideas?

As for RAM voltages, I noticed that my MB was downclocking the OCZ reapers and feeding them with not enough voltage as the manufacturer site indicates that they should run @ 1,65V and the MB set it to 1,5 default. Timings too were @ 9-9-9-24, I set them to 8-8-8-24 and 1600MhZ instead of 1333. I'll see for a couple of days how it runs now and wait before testing drivers one by one (or 5 by 5 rather :).

Hi again and thanks for your replies.

I'll try to answer all of the points you raised.

1. Indeed the MB set incorrect values for the RAMs but only as refers to the timings, it set it on auto to 9-9-9-24 instead of 9-9-9-20, voltage was 1.50v.

2. I cannot read current voltages when I set to "manual" as when I choose the manual setting, the LOWEST possible voltage shows up, not the current one, I hope you get what I mean.

3. As for the voltage for reapers, it's true indeed that OCZ programmed 9-9-9-20 and 1.50v into the chips, BUT they add something to that - this comes from their official support forum:

Hello, we program this memory at a lower "safe" speed to insure that it will boot on all motherboards. "Low voltage" refers to the use of 1.65v, rather than higher voltages that other high speed memory can operate at. We clearly post the voltage as 1.65v in all specs.
Thank you

and

Hello, this kit is programmed at 1333mhz for compatibility reasons. We will be happy to assist you with settings to get you running at rated speeds. Please visit our support forums at the link below and post in the mmeory section. Thank you

and

Hello, we aplogize for the difficulties you have had. We have in the past shipped memory fully programmed at rated speeds. Since memory voltages cannot be programmed to insure that proper voltage is applied when booting, the result is that many systems simply will not boot. In the end we receive back a high percentage of "DOA" memory kits that are working perfectly. This is why we program at lower speeds for compatibility.

and a user's input:

This RAM runs at 9-9-9-20 @ 1.5v out of the box. You have to go into your BIOS and manually set it to run at 8-8-8-24 @ 1.65v.
Which basically means that setting it at 8-8-8-24 @ 1.65 does not mean overclocking according to OCZ. Their programmed setting "allows for fixing possible compatibility issues" Perfectly agree though that this info is at least misleading, which was also underlined many times on forums where people posted info on these RAMs.5. I chose AMD to build my PC, for $$$ reasons, so no way back, at least for now.

4. Since setting timings to 8-8-8-24 and voltage 1.65, I haven't seen any BSODs, but I'm sure the fight isn't over yet.

5. What voltage would you suggest then for the memory controller?

6. Final off-top thought: my previous rig, a good old AMD64 was a piece of cake to overclock and work on for a long time without a single BSOD for lightyears, time passed and I can only tell that instead of having less issues, which should be a logical step as tech advances, it's rather the contrary... compatibility issues??? in 2012... come on.

Thanks for answering Dave.

Dave76 said:

There are work arounds for setting AMD CPUs to handle 1600MHz.
It takes a lot of testing and setting changes.

The support information I've seen from OCZ is less than optimal.

I agree.

Dave76 said:

We are trying to get the RAM in a stable condition, the noted compatibility issues, to see if anything else is causing your system to crash.
OCZ standard official setting is the best way to do this, as they have stated.

I recommend to set the RAM at 1333MHz, 9-9-9-20 RAM timings, Command Rate to 2T.
Set the DRAM voltage manually to 1.60v.

I set the speed to 1333, timings as suggested and I lowered the voltage to 1.60v

Dave76 said:

Set the CPU/NB manually to 1.250v.

Which voltage are you referring to?

Attachment 196754

Dave76 said:

You can change your RAM settings after the analysis is complete, then you will know if you are having a RAM/hardware issue or something else is causing the crashes.

These settings are conservative and should run stable.
To check them, run memtest86+ for 7 full passes with both RAM cards installed, best to run overnight.
If you get any errors you can stop the test.
RAM - Test with Memtest86+

Will do tonight.