Random BSOD on Win7 64-bit

Test update:

#1 Test - stick 1 on socket 1
1h 08mins - 3 pass - no errors

#2 Test - stick 2 on socket 1
1h 11mins - 3 pass - no errors

#3 Test - stick 3 on socket 1
6h 10mins - 13 pass - no errors

#4 Test - stick 4 on socket 1
10h 12mins - 22 pass - no errors

#5 Test - stick 1 on socket 1 & stick 2 on socket 2
10mins - 0 pass - ERRORS

I'm going to test the socket 2 alone with all the sticks.
If you have any advice after reading the result up here, they are more then welcome.

Kindly,

I used my PC a bit today, with all the sticks (2x4 GB by Corsair) just to play (the game I played is really heavy on the Graphic Card)/surf as "daily routine", and, indeed, it crashes again. I have matched sticks with the same serial number on the same channel (four DIMMs - dual-channel operation).

The following are the two latest dumps from WinDbg (x64), both of them are caused by: WerFault.exe - do you see anything interesting ?
And a question that comes into my mind - Could it be that the PSU (it's just a 550w) can't handle the whole system (maybe it's faulty) and cause these memory corruption errors ?

I'm going to continue the tests on the sticks as Carl said, more to follow, thx!

Code:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\110710-22885-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (6 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff800`01a5c000 PsLoadedModuleList = 0xfffff800`01c99e50
Debug session time: Sun Nov  7 10:58:46.825 2010 (UTC + 1:00)
System Uptime: 0 days 0:48:51.324
Loading Kernel Symbols
...............................................................
................................................................
....................
Loading User Symbols
Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffff683ff672eb8, 0, 0, fffff80001afc9fa}

Probably caused by : memory_corruption ( nt!MiSwapWslEntries+6a )

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

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: fffff683ff672eb8, memory referenced
Arg2: 0000000000000000, 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: fffff80001afc9fa, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80001d040e0
 fffff683ff672eb8 

CURRENT_IRQL:  0

FAULTING_IP: 
nt!MiSwapWslEntries+6a
fffff800`01afc9fa 498b00          mov     rax,qword ptr [r8]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  WerFault.exe

TRAP_FRAME:  fffff880076cf630 -- (.trap 0xfffff880076cf630)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000098000000000 rbx=0000000000000000 rcx=0000000fffffffff
rdx=000000000000078b rsi=0000000000000000 rdi=0000000000000000
rip=fffff80001afc9fa rsp=fffff880076cf7c0 rbp=fffffa80096c93f8
 r8=fffff683ff672eb8  r9=000007fece5d7009 r10=fffff70001080488
r11=000000000000096e r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po cy
nt!MiSwapWslEntries+0x6a:
fffff800`01afc9fa 498b00          mov     rax,qword ptr [r8] ds:f760:fffff683`ff672eb8=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80001acbca9 to fffff80001acc740

STACK_TEXT:  
fffff880`076cf4e8 fffff800`01acbca9 : 00000000`0000000a fffff683`ff672eb8 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff880`076cf4f0 fffff800`01aca920 : 00000000`00000000 fffffa80`00000028 fffff880`076cf700 00000000`00000001 : nt!KiBugCheckDispatch+0x69
fffff880`076cf630 fffff800`01afc9fa : fffffa80`06a35350 fffff880`076cfb40 fffff880`076cf850 fffffa80`09003ab0 : nt!KiPageFault+0x260
fffff880`076cf7c0 fffff800`01ae81d2 : 00000000`01000001 000007fe`fbdb1001 fffff700`01080000 fffff880`076cfb40 : nt!MiSwapWslEntries+0x6a
fffff880`076cf820 fffff800`01af31fd : 00000000`0000078b 00000000`00000000 00000000`00000000 fffff880`076cf8f0 : nt!MiUpdateWsle+0xd2
fffff880`076cf880 fffff800`01af2b83 : 78b00001`ef306025 00000001`ef306121 00000000`00000000 00000000`00000000 : nt!MiCompleteProtoPteFault+0x2cd
fffff880`076cf910 fffff800`01ae85be : 00000000`00000000 000007fe`fbdb1720 fffff683`ff7ded88 fffffa80`096c93f8 : nt!MiResolveProtoPteFault+0x1d3
fffff880`076cf9b0 fffff800`01ae6743 : 00000000`00000000 000007fe`fbdb1720 fffffa80`08ad1e50 fffffa80`00000000 : nt!MiDispatchFault+0x1de
fffff880`076cfac0 fffff800`01aca82e : 00000000`00000008 00000000`00000094 00000000`77ad3501 00000000`c0000034 : nt!MmAccessFault+0x343
fffff880`076cfc20 000007fe`fbdb1720 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x16e
00000000`0288ef48 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7fe`fbdb1720


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiSwapWslEntries+6a
fffff800`01afc9fa 498b00          mov     rax,qword ptr [r8]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  nt!MiSwapWslEntries+6a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4c1c44a9

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0xA_nt!MiSwapWslEntries+6a

BUCKET_ID:  X64_0xA_nt!MiSwapWslEntries+6a

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

Code:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\110710-27206-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (6 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff800`01a4f000 PsLoadedModuleList = 0xfffff800`01c8ce50
Debug session time: Sun Nov  7 12:27:15.621 2010 (UTC + 1:00)
System Uptime: 0 days 1:03:24.481
Loading Kernel Symbols
...............................................................
................................................................
...................
Loading User Symbols
Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffff680003b83b8, 0, 0, fffff80001a93a37}

Probably caused by : memory_corruption ( nt!MiDeleteAddressesInWorkingSet+11b )

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

5: 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: fffff680003b83b8, memory referenced
Arg2: 0000000000000000, 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: fffff80001a93a37, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80001cf70e0
 fffff680003b83b8 

CURRENT_IRQL:  0

FAULTING_IP: 
nt!MiDeleteAddressesInWorkingSet+11b
fffff800`01a93a37 488b1e          mov     rbx,qword ptr [rsi]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  WerFault.exe

TRAP_FRAME:  fffff880076d7640 -- (.trap 0xfffff880076d7640)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000098000000000 rbx=0000000000000000 rcx=00000000000001e9
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80001a93a37 rsp=fffff880076d77d0 rbp=fffff70001080518
 r8=fffffa80094923f8  r9=0000000000000001 r10=0000000000000000
r11=fffff70001080000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po cy
nt!MiDeleteAddressesInWorkingSet+0x11b:
fffff800`01a93a37 488b1e          mov     rbx,qword ptr [rsi] ds:000b:00000000`00000000=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80001abeca9 to fffff80001abf740

STACK_TEXT:  
fffff880`076d74f8 fffff800`01abeca9 : 00000000`0000000a fffff680`003b83b8 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff880`076d7500 fffff800`01abd920 : 00000000`00000000 0000000f`ffffffff 00000000`00001000 fffff800`01bf3bfe : nt!KiBugCheckDispatch+0x69
fffff880`076d7640 fffff800`01a93a37 : 00000003`00000000 81100002`1cddc025 fffff700`01080510 fffff683`fffffdb8 : nt!KiPageFault+0x260
fffff880`076d77d0 fffff800`01a9268a : fffffa80`09492060 fffffa80`00000000 fffff8a0`00000000 00000000`00000000 : nt!MiDeleteAddressesInWorkingSet+0x11b
fffff880`076d8080 fffff800`01da4dcf : fffff8a0`033bd060 00000000`00000001 00000000`00000000 fffffa80`095c8060 : nt!MmCleanProcessAddressSpace+0x96
fffff880`076d80d0 fffff800`01d7c85b : 00000000`c0000005 00000000`00000001 000007ff`fffde000 00000000`00000000 : nt!PspExitThread+0x92f
fffff880`076d8190 fffff800`01abe993 : fffffa80`09492060 fffff800`c0000005 ffffcfd5`3d01a8dd fffffa80`095c8060 : nt!NtTerminateProcess+0x25b
fffff880`076d8210 fffff800`01abaf30 : fffff800`01af9dbc fffff880`076d8b78 fffff880`076d88e0 fffff880`076d8c20 : nt!KiSystemServiceCopyEnd+0x13
fffff880`076d83a8 fffff800`01af9dbc : fffff880`076d8b78 fffff880`076d88e0 fffff880`076d8c20 00000000`00000000 : nt!KiServiceLinkage
fffff880`076d83b0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0x53b


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiDeleteAddressesInWorkingSet+11b
fffff800`01a93a37 488b1e          mov     rbx,qword ptr [rsi]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  nt!MiDeleteAddressesInWorkingSet+11b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4c1c44a9

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0xA_nt!MiDeleteAddressesInWorkingSet+11b

BUCKET_ID:  X64_0xA_nt!MiDeleteAddressesInWorkingSet+11b

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

And a question that comes into my mind - Could it be that the PSU (it's just a 550w) can't handle the whole system ?

Asus approved, I used this tool: http://support.asus.com/PowerSupplyC...tor_right.aspx

I found a possible cause with the Channel Interleaving option on BIOS.
It seems that the AMD CPU, works best with this setting: XOR of Address Bits [20:16,9]

Another possible cause, may be the "Enable Memory Hole Remapping" enabled (it seems to cause problems with the drivers in general, more with audio one's).
I'm scouting around to gather more info and I will run ram tests later tonight while sleeping. This is another update:

#6 Test - stick 1 on socket 2
2h 30mins - 6 pass - OK

#7 Test - stick 2 on socket 2
10h 15mins - 13 pass - OK

#8 Test - stick 3 on socket 2
1h 00mins - 3 pass - OK

Previous Tests said:

#1 Test - stick 1 on socket 1
1h 08mins - 3 pass - OK

#2 Test - stick 2 on socket 1
1h 11mins - 3 pass - OK

#3 Test - stick 3 on socket 1
6h 10mins - 13 pass - OK

#4 Test - stick 4 on socket 1
10h 12mins - 22 pass - OK

#5 Test - stick 1 on socket 1 & stick 2 on socket 2
10mins - 0 pass - ERRORS

Kindly,

I run a memtest with all sticks (4x2GB) for 7hours (4 pass), in attach the result.
The "Errors per Memory Slot" shows errors on socket 1, isn't it? (red square on screen).

I'm currently running a test on that, socket 1, with the same stick that *should* be faulty.

CarlTR6 said:

... By the way, please upload the dumps to us rather than posting the WinDBug results. There are commands we can run on the dump file that gives us additional information.

I will attach all the batch result, when I get home, thx!
Kindly,

lwrand said:

I run a memtest with all sticks (4x2GB) for 7hours (4 pass), in attach the result.
The "Errors per Memory Slot" shows errors on socket 1, isn't it? (red square on screen).

I'm currently running a test on that, socket 1, with the same stick that *should* be faulty.

CarlTR6 said:

... By the way, please upload the dumps to us rather than posting the WinDBug results. There are commands we can run on the dump file that gives us additional information.

I will attach all the batch result, when I get home, thx!
Kindly,

One RAM stick is faulty, replace it

yowanvista said:

One RAM stick is faulty, replace it

Hi yowanvista, you mean exactly the stick in socket 1, right ?.
I'm asking for confirmation because I can't understand the 0 - 1 - 2 - 3 numbers near the errors (1) - They shoud point to socket 1, isn't it ?

Thx for your time!

I have run one more memtest (3 sticks only - 1 dual channel and 1 single), here the result.

Later on i'm going to post the full dump batch of the previous two BSOD (IRQL_NOT_LESS_OR_EQUAL) involving the process: WerFault.exe

At the moment, I'm asking for another RMA on RAMs (dunno which one...). If it's not gonna work, probably, there can be a problem with the motherboard on managing dual channel RAM (maybe caused by the high temperature). Corsair suggests to use an additional cooling sytem, placed on RAMs, with more then two sticks,

Could it be the *real* problem ?

Things are getting worst than I thought,