Crash dump

EasyPC said:

I uploaded another crash dump (from today). Looks like increasing the ram voltage from 1.8 to 1.9 didn't help much. I went to bios and set 2.0 V after the reboot. I hope it helps.

Hi and welcome

It still is memory corruption. You should
download memtestx86 and run for at least 5 passes.

run a system file check
type cmd in search>right click and run as admin>sfc /scannow

let us know the results


Ken

Code:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\K\Desktop\020710-19780-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*d:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02818000 PsLoadedModuleList = 0xfffff800`02a55e50
Debug session time: Sun Feb  7 12:15:27.399 2010 (GMT-5)
System Uptime: 3 days 2:03:01.402
Loading Kernel Symbols
...............................................................
................................................................
................
Loading User Symbols
Loading unloaded module list
...................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffff68000107608, 0, 0, fffff8000289dae2}

Probably caused by : memory_corruption ( nt!MiAgeWorkingSet+1c2 )

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

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: fffff68000107608, 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: fffff8000289dae2, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002ac00e0
 fffff68000107608 

CURRENT_IRQL:  0

FAULTING_IP: 
nt!MiAgeWorkingSet+1c2
fffff800`0289dae2 488b19          mov     rbx,qword ptr [rcx]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  wlcomm.exe

TRAP_FRAME:  fffff880031167a0 -- (.trap 0xfffff880031167a0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000007ffffffff8 rbx=0000000000000000 rcx=fffff68000107608
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000289dae2 rsp=fffff88003116930 rbp=000000000010760e
 r8=0000000000000001  r9=fffffa8003ad8d08 r10=0000000000000005
r11=0000000000000003 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe cy
nt!MiAgeWorkingSet+0x1c2:
fffff800`0289dae2 488b19          mov     rbx,qword ptr [rcx] ds:fffff680`00107608=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002889469 to fffff80002889f00

STACK_TEXT:  
fffff880`03116658 fffff800`02889469 : 00000000`0000000a fffff680`00107608 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff880`03116660 fffff800`028880e0 : 00000000`00000000 00000980`00000000 00000000`00000000 00000000`00000002 : nt!KiBugCheckDispatch+0x69
fffff880`031167a0 fffff800`0289dae2 : 00000003`00000000 2cc00000`36c94025 00000000`00000000 00000000`000002cc : nt!KiPageFault+0x260
fffff880`03116930 fffff800`0290aa0e : fffffa80`03ad8d08 fffff880`00000001 00000000`00000001 fffff880`03116bb0 : nt!MiAgeWorkingSet+0x1c2
fffff880`03116ae0 fffff800`0289e6e2 : 00000000`00001158 00000000`00000000 fffffa80`00000000 00000000`00000005 : nt! ?? ::FNODOBFM::`string'+0x49926
fffff880`03116b80 fffff800`0289e96f : 00000000`00000008 fffff880`03116c10 00000000`00000001 fffffa80`00000000 : nt!MmWorkingSetManager+0x6e
fffff880`03116bd0 fffff800`02b2d166 : fffffa80`01872680 00000000`00000080 fffffa80`0184f890 00000000`00000001 : nt!KeBalanceSetManager+0x1c3
fffff880`03116d40 fffff800`02868486 : fffff800`02a02e80 fffffa80`01872680 fffff800`02a10c40 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03116d80 00000000`00000000 : fffff880`03117000 fffff880`03111000 fffff880`03116710 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiAgeWorkingSet+1c2
fffff800`0289dae2 488b19          mov     rbx,qword ptr [rcx]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  nt!MiAgeWorkingSet+1c2

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc600

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0xA_nt!MiAgeWorkingSet+1c2

BUCKET_ID:  X64_0xA_nt!MiAgeWorkingSet+1c2

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

The first attempt to start sfc resulted in a crash (crash dump attached).

The second time (right after the reboot) was successful:

C:\Windows\system32>sfc /scannow

Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection did not find any integrity violations.

EasyPC said:

The first attempt to start sfc resulted in a crash (crash dump attached).

The second time (right after the reboot) was successful:

C:\Windows\system32>sfc /scannow

Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection did not find any integrity violations.

question is will you ever be able to get this ram to work on this motherboard ??

Probably not, but first I want to make sure it's really RAM issue, not CPU.

Here are 2 more minidumps from today, just in case if it points out to something else.

EasyPC said:

Probably not, but first I want to make sure it's really RAM issue, not CPU.

Here are 2 more minidumps from today, just in case if it points out to something else.

Win debugger shows

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 116, {fffffa80020644e0, fffff88004039cb0, 0, c}

Unable to load image igdkmd64.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for igdkmd64.sys
*** ERROR: Module load completed but symbols could not be loaded for igdkmd64.sys
Probably caused by : igdkmd64.sys ( igdkmd64+23cb0 )

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

It may be worth checking to see if yours is the latest driver version

igdkmd64.sys fffff880`04004000 fffff87f`045d7500 0xffffffff005d3500 0x4a01d55b 06/05/2009 18:22:19

which I've seen fixed before by updating bios , I believe it relates to an onboard video graphics accelerator ?

the second was ntkrnlmp.exe again which is a symptom not a cause

Problem SOLVED.

CPU is damaged due to overclocking (of it's previous owner) and needs an increase of vcore in bios to function properly.

Thanks for help everybody