BSOD every morning on my 1st PC build :( HELP please

arron911

Distinguished
Aug 5, 2010
5
0
18,510
Hi, thank you for having a look at this post. I'm struggling with not many choices left of what I can do.

This is my first attempt at building a pc and i thought it all went a bit too well. Next morning and every morning since (i.e. after the pc has been off for several hours), I get the dreaded BSOD as soon as Windows 7 loads up.

After deliberation and price constraints I decided upon:

Windows 7 professional 64
AMD Phenom II X2 555 Black Edition 3.2GHz Socket AM3 6MB Cache Retail Box Processor
Asus M4A88TD-V EVO/USB3 880G Socket AM3 8 Channel Audio ATX Motherboard
TW3X4G1333C9A - 4GB (2x2GB) Corsair XMS3 Classic, DDR3 PC3-10666 (1333) Non-ECC Unbuffered, CAS 9-9-9-24, 1.50V
Corsair 400W CX PSU - 12cm Fan 80Plus Certified Efficiency 6x SATA 1x PCI-E

All seem to work well after the initial daily hiccup. It will BS a couple of times then be fine till the next day.

I've ran prime 95 for a couple of hours and memtest overnight and no errors came up.

As I bought these components separately I’m not sure where I stand on warranty as all the parts were purchased individually and even collectively i guess are operational.

I'm assuming its hardware as I have reinstalled Windows 7 pro 64 two days ago and got the BSOD again the very next day.

If someone manages to get to the bottom of this I would feel like kissing them, but instead will jump around the room for a moment and offer a firm handshake.

Thank you once again for taking the time to consider this.
 

arron911

Distinguished
Aug 5, 2010
5
0
18,510
Minidump 1

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


Loading Dump File [C:\Windows\Minidump\080410-21637-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 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Machine Name:
Kernel base = 0xfffff800`02c05000 PsLoadedModuleList = 0xfffff800`02e42e50
Debug session time: Wed Aug 4 11:24:26.212 2010 (UTC + 1:00)
System Uptime: 0 days 0:01:05.648
Loading Kernel Symbols
...............................................................
................................................................
..................................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 19, {3, fffffa800365dcb0, fffffa800365dcb0, fffffa800367dcb0}

Probably caused by : Pool_Corruption ( nt!ExFreePool+536 )

Followup: Pool_corruption
---------

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

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000003, the pool freelist is corrupt.
Arg2: fffffa800365dcb0, the pool entry being checked.
Arg3: fffffa800365dcb0, the read back flink freelist value (should be the same as 2).
Arg4: fffffa800367dcb0, the read back blink freelist value (should be the same as 2).

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


BUGCHECK_STR: 0x19_3

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: WerFault.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002da8d6f to fffff80002c75600

STACK_TEXT:
fffff880`084ed1a8 fffff800`02da8d6f : 00000000`00000019 00000000`00000003 fffffa80`0365dcb0 fffffa80`0365dcb0 : nt!KeBugCheckEx
fffff880`084ed1b0 fffff800`02c9d8f4 : fffffa80`00000000 fffffa80`067c0d10 00000000`00000008 00000000`00000000 : nt!ExFreePool+0x536
fffff880`084ed2a0 fffff800`02c9ee14 : fffffa80`0370b1c0 00000000`00000100 fffff6fc`c005d400 fffff880`084ed3a0 : nt!MiAddViewsForSection+0x1d4
fffff880`084ed330 fffff800`02c9e2d7 : fffff8a0`02d837e0 fffff800`02df0530 fffff880`084ed4d8 fffff8a0`03397fd0 : nt!MmMapViewInSystemCache+0x194
fffff880`084ed4a0 fffff800`02c94170 : 00000000`00000000 00000000`000df600 00000000`00000000 00000000`00000000 : nt!CcGetVacbMiss+0x177
fffff880`084ed560 fffff800`02f938d2 : 00000000`000c0000 00000000`000df600 fffff880`084ed630 fffff880`084ed6c0 : nt!CcGetVirtualAddress+0x1b0
fffff880`084ed5f0 fffff880`01248fc0 : fffff8a0`00000000 fffff880`00000005 fffffa80`0676aac0 fffff880`0129c001 : nt!CcCopyRead+0x132
fffff880`084ed6b0 fffff880`0124d303 : 00000000`000df600 fffff8a0`03833b40 fffff880`084ed8e0 fffff880`084ed7d8 : Ntfs!NtfsCachedRead+0x180
fffff880`084ed710 fffff880`0124ff78 : fffffa80`0676aac0 fffffa80`06b3b010 fffff880`084ed801 fffffa80`069f6800 : Ntfs!NtfsCommonRead+0x583
fffff880`084ed8b0 fffff880`0105923f : fffffa80`06b3b3b0 fffffa80`06b3b010 fffffa80`069f6830 00000000`00000001 : Ntfs!NtfsFsdRead+0x1b8
fffff880`084ed960 fffff880`010576df : fffffa80`055cd3e0 00000000`00000001 fffffa80`055cd300 fffffa80`06b3b010 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880`084ed9f0 fffff800`02f8cc49 : 00000000`00000000 fffffa80`069ab5f0 00000000`00000001 fffffa80`06b3b010 : fltmgr!FltpDispatch+0xcf
fffff880`084eda50 fffff800`02f94453 : fffffa80`069ab5f0 fffffa80`069ab5f0 fffffa80`069ab5f0 fffffa80`069ab501 : nt!IopSynchronousServiceTail+0xf9
fffff880`084edac0 fffff800`02c74853 : 00000000`00000108 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtReadFile+0x631
fffff880`084edbb0 00000000`76ddfdba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0023b408 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76ddfdba


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ExFreePool+536
fffff800`02da8d6f cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!ExFreePool+536

FOLLOWUP_NAME: Pool_corruption

IMAGE_NAME: Pool_Corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MODULE_NAME: Pool_Corruption

FAILURE_BUCKET_ID: X64_0x19_3_nt!ExFreePool+536

BUCKET_ID: X64_0x19_3_nt!ExFreePool+536

Followup: Pool_corruption
---------
 

arron911

Distinguished
Aug 5, 2010
5
0
18,510
Minidump 2



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


Loading Dump File [C:\Windows\Minidump\080410-24117-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 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Machine Name:
Kernel base = 0xfffff800`02c1f000 PsLoadedModuleList = 0xfffff800`02e5ce50
Debug session time: Wed Aug 4 11:26:00.182 2010 (UTC + 1:00)
System Uptime: 0 days 0:00:46.618
Loading Kernel Symbols
...............................................................
................................................................
...................................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1A, {3452, 7feffc2a000, fffff70001081690, 0}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+33a23 )

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

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

MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000003452, The subtype of the bugcheck.
Arg2: 000007feffc2a000
Arg3: fffff70001081690
Arg4: 0000000000000000

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


BUGCHECK_STR: 0x1a_3452

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: userinit.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002d02fb3 to fffff80002c8f600

STACK_TEXT:
fffff880`066121d8 fffff800`02d02fb3 : 00000000`0000001a 00000000`00003452 000007fe`ffc2a000 fffff700`01081690 : nt!KeBugCheckEx
fffff880`066121e0 fffff800`02c625a2 : fffffa80`065d8420 fffffa80`00000000 fffff8a0`00000079 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x33a23
fffff880`06612a90 fffff800`02f75c4f : fffff8a0`02672060 00000000`00000001 00000000`00000000 fffffa80`06625060 : nt!MmCleanProcessAddressSpace+0x96
fffff880`06612ae0 fffff800`02f4d6eb : 00000000`00000000 00000000`00000001 000007ff`fffde000 00000000`00000000 : nt!PspExitThread+0x92f
fffff880`06612ba0 fffff800`02c8e853 : fffffa80`065d8420 fffff880`00000000 00000000`00403cc0 fffffa80`06625060 : nt!NtTerminateProcess+0x25b
fffff880`06612c20 00000000`77aa001a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0020fac8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77aa001a


STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+33a23
fffff800`02d02fb3 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+33a23

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4b88cfeb

FAILURE_BUCKET_ID: X64_0x1a_3452_nt!_??_::FNODOBFM::_string_+33a23

BUCKET_ID: X64_0x1a_3452_nt!_??_::FNODOBFM::_string_+33a23

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

arron911

Distinguished
Aug 5, 2010
5
0
18,510
Appreciate the help guys. It turns out it was faulty RAM which memtest did not pick up. With one stick in of a morning the BSOD would happen repeatedly where as with the other in it would load up perfectly. Switched back to retest a couple of times and always same result.