Hi,
2 dmp = 0x1A (Memory Management)
1 dmp = 0x109 (CRITICAL_STRUCTURE_CORRUPTION)
It can be caused by bad RAM or 3rd drivers.
Have you tried memtest86 for each stick individually and with different slot?
Because the possibilities are:
- Mismatch pair of RAM
- Bad stick of RAM
- Bad motherboard slot
RAM - Test with Memtest86+
Then I see you have several drivers that need to be updated:
Code:
WinRing0x64.sys Sat Jul 26 06:29:37 2008 → WinRing
SSLDrv.sys Thu Jan 31 14:58:38 2008 → SSL VPN Net Extender
spc1300.sys Wed Dec 10 19:23:23 2008 → USB PC Camera
spc1300c.SYS Sun Nov 09 23:14:15 2008 → USB PC Camera
phaudlwr.sys Wed May 07 02:40:14 2008 → Philips USB Audio Processing
lmimirr.sys Tue Apr 10 15:32:45 2007 → Miniport Driver or LogMeIn
LMIRfsDriver.sys Mon Jul 14 09:26:56 2008 → Miniport Driver or LogMeIn
RaInfo.sys Fri Jan 04 10:57:14 2008 → LogMeIn/RemotelyAnywhere Kernel
Rt64win7.sys Thu Feb 26 01:04:13 2009 → Realtek NIC driver
RTKVHD64.sys Fri Dec 25 02:41:24 2009 → Realtek HD Audio
Code:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 109, {a3a039d8a0e1453f, 0, 854c4196fec09310, 101}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
4: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d8a0e1453f, Reserved
Arg2: 0000000000000000, Reserved
Arg3: 854c4196fec09310, Failure type dependent information
Arg4: 0000000000000101, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification
Debugging Details:
------------------
BUGCHECK_STR: 0x109
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80002ebf740
STACK_TEXT:
fffff880`033775d8 00000000`00000000 : 00000000`00000109 a3a039d8`a0e1453f 00000000`00000000 854c4196`fec09310 : nt!KeBugCheckEx
STACK_COMMAND: kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: BAD_STACK
Followup: MachineOwner
---------