BSOD's Memory I think... Maybe Motherboard memory controller?

[Krytical]

This is not about my system it is about another system...


Someone I know is getting a lot of blue screens randomly but quite often, there is nothing really connecting the BSOD's except the same message some of the time... Memory management... but there were about 3 other BSOD codes given at different times.... Ran Memtest over a weekend, found memory 11 errors, replaced all the memory, still getting BSOD's, ran CHKDSK /B and SFC /scannow as well as startup repairs, and windows repair from the disk, and despite everything showing as OK, she is still gettings BSODS....

So now I'm down to analyzing the dumps, I've gotten as far as opening the dumps up and being able to read them, but I can't make much sense of what could be the problem from here... I have two dumps from today, from what I can gather, its still the memory even though its 4 different chips... Now I'm trying to figure out if its the memory or maybe the motherboard? I don't know if I'm even able to figure that out by these logs... Any help in deciphering these logs, or other tips of how to properly figure this stuff out myself would be greatly appreciated!

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

Loading Dump File [C:\Users\Brandoni.WII\Desktop\112811-30451-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 (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`03049000 PsLoadedModuleList = 0xfffff800`0328e670
Debug session time: Mon Nov 28 09:25:51.575 2011 (UTC - 8:00)
System Uptime: 0 days 0:10:32.074
Loading Kernel Symbols
...............................................................
................................................................
.........................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1A, {403, fffff6800009e7b0, a6500001068b3847, fffff6800009e790}
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+330bc )
Followup: MachineOwner
---------
2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
MEMORY_MANAGEMENT (1a)
    # Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000000403, The subtype of the bugcheck.
Arg2: fffff6800009e7b0
Arg3: a6500001068b3847
Arg4: fffff6800009e790
Debugging Details:
------------------

BUGCHECK_STR:  0x1a_403
CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
PROCESS_NAME:  svchost.exe
CURRENT_IRQL:  0
LAST_CONTROL_TRANSFER:  from fffff8000306d3f6 to fffff800030c5c40
STACK_TEXT:  
fffff880`078b4678 fffff800`0306d3f6 : 00000000`0000001a 00000000`00000403 fffff680`0009e7b0 a6500001`068b3847 : nt!KeBugCheckEx
fffff880`078b4680 fffff800`030f7bb7 : fffffa80`089bdb00 fffff680`0009e7b8 fffffa80`089bdb30 a2000000`cca26867 : nt! ?? ::FNODOBFM::`string'+0x330bc
fffff880`078b4830 fffff800`030f9569 : fffffa80`00000000 00000000`13cfffff 00000000`00000000 fffff800`03250348 : nt!MiDeleteVirtualAddresses+0x41f
fffff880`078b49f0 fffff800`033dd221 : fffffa80`094b7ef0 00000000`00000000 fffffa80`070564c0 fffffa80`070564c0 : nt!MiRemoveMappedView+0xd9
fffff880`078b4b10 fffff800`033dd623 : fffff880`00000000 00000000`13cf0000 fffffa80`00000001 00000000`00000001 : nt!MiUnmapViewOfSection+0x1b1
fffff880`078b4bd0 fffff800`030c4ed3 : ffffffff`ffffffff 00000000`0325ed48 fffffa80`089bdb30 00000000`00008000 : nt!NtUnmapViewOfSection+0x5f
fffff880`078b4c20 00000000`76d915ba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0325ecd8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76d915ba

STACK_COMMAND:  kb
FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+330bc
fffff800`0306d3f6 cc              int     3
SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+330bc
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: nt
IMAGE_NAME:  ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3
FAILURE_BUCKET_ID:  X64_0x1a_403_nt!_??_::FNODOBFM::_string_+330bc
BUCKET_ID:  X64_0x1a_403_nt!_??_::FNODOBFM::_string_+330bc
Followup: MachineOwner
---------

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

Loading Dump File [C:\Users\Brandoni.WII\Desktop\112811-20389-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 (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`03006000 PsLoadedModuleList = 0xfffff800`0324b670
Debug session time: Mon Nov 28 09:14:18.420 2011 (UTC - 8:00)
System Uptime: 0 days 0:02:00.053
Loading Kernel Symbols
...............................................................
................................................................
.......................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 109, {a3a039d89869c88d, b3b7465eeae697e3, fffff80003076130, 1}
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : memory_corruption
Followup: memory_corruption
---------
3: 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 [url=http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx]Patching Policy for x64-Based Systems[/url]
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: a3a039d89869c88d, Reserved
Arg2: b3b7465eeae697e3, Reserved
Arg3: fffff80003076130, Failure type dependent information
Arg4: 0000000000000001, 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:  CODE_CORRUPTION
PROCESS_NAME:  System
CURRENT_IRQL:  0
LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff80003082c40
STACK_TEXT:  
fffff880`031a85d8 00000000`00000000 : 00000000`00000109 a3a039d8`9869c88d b3b7465e`eae697e3 fffff800`03076130 : nt!KeBugCheckEx

STACK_COMMAND:  kb
CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
    fffff800030761a0 - nt!KiDeliverApc+70
 [ 3a:1a ]
1 error : !nt (fffff800030761a0)
MODULE_NAME: memory_corruption
IMAGE_NAME:  memory_corruption
FOLLOWUP_NAME:  memory_corruption
DEBUG_FLR_IMAGE_TIMESTAMP:  0
MEMORY_CORRUPTOR:  ONE_BIT
FAILURE_BUCKET_ID:  X64_MEMORY_CORRUPTION_ONE_BIT
BUCKET_ID:  X64_MEMORY_CORRUPTION_ONE_BIT
Followup: memory_corruption
---------

 

[zigzag3143]

We do need the actual DMP file as it contains the only record of the sequence of events leading up to the crash, what drivers were loaded, and what was responsible.

It is almost impossible to spot trends from a single DMP file so if you have more than one please upload them. If you only have one please wait until the computer crashes again then upload both.

You may be able to get the DMP files without crashing by booting into safe mode (F8) with networking.

To enable us to assist you with your computer's BSOD symptoms, upload the contents of your "\Windows\Minidump" folder.



The procedure:

* Copy the contents of \Windows\Minidump to another (temporary) location somewhere on your machine.
* Zip up the copy.
* Attach the ZIP archive to your post using the "paperclip" (file attachments) button.
*If the files are too large please upload them to a file sharing service like "Rapidshare" and put a link to them in your reply.

To ensure minidumps are enabled:

* Go to Start, in the Search Box type: sysdm.cpl, press Enter.
* Under the Advanced tab, click on the Startup and Recovery Settings... button.
* Ensure that Automatically restart is unchecked.
* Under the Write Debugging Information header select Small memory dump (256 kB) in the dropdown box (the 256kb varies).
* Ensure that the Small Dump Directory is listed as %systemroot%\Minidump.
* OK your way out.
* Reboot if changes have been made.

 

[Krytical]

Oh ok, good to know (about the dmp files containing more info than what I had posted) and I just realized how much more info there is here on this subject, reading time!

3 .dmp files attached

 

[zigzag3143]

Oh ok, good to know (about the dmp files containing more info than what I had posted) and I just realized how much more info there is here on this subject, reading time!

3 .dmp files attached

These crashes were caused by memory management (probably a driver). Please run these two tests to verify your memory and find which driver is causing the problem.


1-Memtest.

*Download a copy of Memtest86 and burn the ISO to a CD using Iso Recorder or another ISO burning program. Memtest86+ - Advanced Memory Diagnostic Tool

*Boot from the CD, and leave it running for at least 5 or 6 passes.

Just remember, any time Memtest reports errors, it can be either bad RAM or a bad motherboard slot.

Test the sticks individually, and if you find a good one, test it in all slots.

Any errors are indicative of a memory problem.

If a known good stick fails in a motherboard slot it is probably the slot.

http://www.sevenforums.com/tutorials/105647-ram-test-memtest86.html



2-Driver verifier

I'd suggest that you first backup your data and then make sure you've got access to another computer so you can contact us if problems arise. Then make a System Restore point (so you can restore the system using the Vista/Win7 Startup Repair feature).

In Windows 7 you can make a Startup Repair disk by going to Start....All Programs...Maintenance...Create a System Repair Disc - with Windows Vista you'll have to use your installation disk or the "Repair your computer" option at the top of the Safe Mode menu .

Then, here's the procedure:
- Go to Start and type in "verifier" (without the quotes) and press Enter
- Select "Create custom settings (for code developers)" and click "Next"
- Select "Select individual settings from a full list" and click "Next"
- Select everything EXCEPT FOR "Low Resource Simulation" and click "Next"
- Select "Select driver names from a list" and click "Next"
Then select all drivers NOT provided by Microsoft and click "Next"
- Select "Finish" on the next page.

Reboot the system and wait for it to crash to the Blue Screen. Continue to use your system normally, and if you know what causes the crash, do that repeatedly. The objective here is to get the system to crash because Driver Verifier is stressing the drivers out. If it doesn't crash for you, then let it run for at least 36 hours of continuous operation (an estimate on my part).

If you can't get into Windows because it crashes too soon, try it in Safe Mode.
If you can't get into Safe Mode, try using System Restore from your installation DVD to set the system back to the previous restore point that you created.

http://www.sevenforums.com/tutorials/101379-driver-verifier-enable-disable.html