Occasional blue screen after processor upgrade

[dirtydan]

System was rock solid until processor upgrade from X3 450 to a X4 970. I started getting random blue screens about once a month, general video driver weirdness like the drivers needing to be reinstalled after a reboot.

Did a complete manual uninstall and reinstall of my video drivers, all was fine for a month then Friday had a bad pool header, dxgmms1.sys BSOD.

I wonder if I need to adjust some RAM settings in the bios? I can get a screenshot of my current settings.

Current bios is compatible with this processor.

I hate to have to reinstall everything, that will take weeks, but I'm preparing for that scenario.

current system:

Coolermaster CM 690 II Advanced
AMD Phenom X4 970 (new)
AMD Athlon X3 450 3.2GHz
ARCTIC COOLING Freezer 7 Pro Rev.2
GIGABYTE GA-970A-UD3 rev 1.1
G.SKILL Ripjaws 8GB (2 x 4GB)  DDR3 1333 F3-10666CL9D-8GBRL
XFX Radeon HD5770
Corsair 650TX 650W
CREATIVE  SB X-Fi Titanium
500GB WD Caviar Black
Dell UltraSharp U2412M

latest crash dump
////////////////////////////////


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


Loading Dump File [C:\Windows\Minidump\110113-12792-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.18113.amd64fre.win7sp1_gdr.130318-1533
Machine Name:
Kernel base = 0xfffff800`0300f000 PsLoadedModuleList = 0xfffff800`03252670
Debug session time: Fri Nov  1 06:33:34.757 2013 (GMT-5)
System Uptime: 0 days 21:45:06.755
Loading Kernel Symbols
...............................................................
................................................................
............................................
Loading User Symbols
Loading unloaded module list
.............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 19, {20, fffff8a00b3b1b30, fffff8a00b3b1ee0, d3b1b68}

Probably caused by : dxgmms1.sys ( dxgmms1!VIDMM_GLOBAL::CloseLocalAllocation+268 )

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

1: 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: 0000000000000020, a pool block header size is corrupt.
Arg2: fffff8a00b3b1b30, The pool entry we were looking for within the page.
Arg3: fffff8a00b3b1ee0, The next pool entry.
Arg4: 000000000d3b1b68, (reserved)

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


OVERLAPPED_MODULE: Address regions for 'Rt64win7' and 'Rt64win7.sys' overlap

BUGCHECK_STR:  0x19_20

POOL_ADDRESS: GetPointerFromAddress: unable to read from fffff800032bc100
 fffff8a00b3b1b30

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  dwm.exe

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff800031b7cae to fffff80003084c00

STACK_TEXT: 
fffff880`085431b8 fffff800`031b7cae : 00000000`00000019 00000000`00000020 fffff8a0`0b3b1b30 fffff8a0`0b3b1ee0 : nt!KeBugCheckEx
fffff880`085431c0 fffff880`047c9de0 : 00000000`00000000 fffff8a0`034fdd80 00000000`7ffff8a0 fffffa80`09b04000 : nt!ExDeferredFreePool+0x12da
fffff880`08543270 fffff880`047c4637 : fffffa80`099140e0 00000000`00000001 fffff8a0`0e7f2ce0 00000000`00000001 : dxgmms1!VIDMM_GLOBAL::CloseLocalAllocation+0x268
fffff880`08543320 fffff880`047aaecc : fffffa80`00000000 00000000`00000000 fffff8a0`10c4d1f0 00000000`00000000 : dxgmms1!VIDMM_GLOBAL::CloseOneAllocation+0x19b
fffff880`085433f0 fffff880`046ecccc : 00000000`00000000 fffff8a0`0352e000 fffff8a0`0352e000 00000000`00000001 : dxgmms1!VidMmCloseAllocation+0x44
fffff880`08543420 fffff880`046ec65f : fffff8a0`0352e000 fffff8a0`0352f300 fffff8a0`00000000 00000c40`00000000 : dxgkrnl!DXGDEVICE::DestroyAllocations+0x248
fffff880`08543510 fffff880`0471a7a3 : 00000000`00000000 fffff8a0`035bdf40 fffff8a0`018726b0 fffff880`08543930 : dxgkrnl!DXGDEVICE::ProcessTerminationList+0xa3
fffff880`08543560 fffff880`04719ecf : fffff8a0`00000799 fffff8a0`018726b0 fffff880`085438c0 fffff880`085438f0 : dxgkrnl!DXGCONTEXT::Present+0x2cb
fffff880`08543880 fffff960`00220438 : fffffa80`0a26fb50 00000000`00000000 fffff8a0`103ce570 00000000`00000010 : dxgkrnl!DxgkPresent+0x543
fffff880`08543bf0 fffff800`03083e93 : fffffa80`0a26fb50 00000000`02b6faf0 000007fe`fa15c610 00000000`00000000 : win32k!NtGdiDdDDIPresent+0x18
fffff880`08543c20 000007fe`fe14145a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`02b6ee68 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7fe`fe14145a


STACK_COMMAND:  kb

FOLLOWUP_IP:
dxgmms1!VIDMM_GLOBAL::CloseLocalAllocation+268
fffff880`047c9de0 4c8d9c2480000000 lea     r11,[rsp+80h]

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  dxgmms1!VIDMM_GLOBAL::CloseLocalAllocation+268

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: dxgmms1

IMAGE_NAME:  dxgmms1.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  5164dc13

FAILURE_BUCKET_ID:  X64_0x19_20_dxgmms1!VIDMM_GLOBAL::CloseLocalAllocation+268

BUCKET_ID:  X64_0x19_20_dxgmms1!VIDMM_GLOBAL::CloseLocalAllocation+268

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


Thanks

[mikeyb5753]

didn't you do a fresh install after the CPU upgrade?

[dirtydan]

Nope, everywhere I googled said thats not required, all other hardware is the same.

[mikeyb5753]

i'd try that, atleast to rule it out

[Ed]

That DLL is for Realtek NIC. I would uninstall and re-install that instead of the whole OS. There might be a newer driver on Realteks site too.

[dirtydan]

Thanks. I have had problems with realtek drivers before.

[AgentFXA]

Bad Pool Header usually is CPU or RAM - have been through that myself when my old 1090T started vomiting on me with lots of BS. After changing to an FX all problems vanished.

  

 

[dirtydan]

My last crash from last Sunday

//////////////////////////////////////////////////////////////////////////



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


Loading Dump File [C:\Windows\Minidump\110313-20732-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.18113.amd64fre.win7sp1_gdr.130318-1533
Machine Name:
Kernel base = 0xfffff800`0305d000 PsLoadedModuleList = 0xfffff800`032a0670
Debug session time: Sun Nov  3 19:20:17.081 2013 (GMT-5)
System Uptime: 0 days 11:13:33.671
Loading Kernel Symbols
...............................................................
................................................................
..............................................
Loading User Symbols
Loading unloaded module list
...................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 50, {fffff910c0e0b750, 0, fffff96000185750, 5}


Could not read faulting driver name
Probably caused by : win32k.sys ( win32k!memmove+250 )

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

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

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffff910c0e0b750, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff96000185750, If non-zero, the instruction address which referenced the bad memory
   address.
Arg4: 0000000000000005, (reserved)

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


Could not read faulting driver name

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff8000330a100
 fffff910c0e0b750

FAULTING_IP:
win32k!memmove+250
fffff960`00185750 488b440af8      mov     rax,qword ptr [rdx+rcx-8]

MM_INTERNAL_CODE:  5

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x50

PROCESS_NAME:  explorer.exe

CURRENT_IRQL:  0

TRAP_FRAME:  fffff88007caca90 -- (.trap 0xfffff88007caca90)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff900c0e0c170 rbx=0000000000000000 rcx=fffff910c0e0c178
rdx=fffffffffffff5e0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff96000185750 rsp=fffff88007cacc28 rbp=ffffffffffffffff
 r8=0000001000000008  r9=0000000080000000 r10=0000000000000002
r11=fffff900c0e0c170 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
win32k!memmove+0x250:
fffff960`00185750 488b440af8      mov     rax,qword ptr [rdx+rcx-8] ds:7530:fffff910`c0e0b750=?
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff8000314f5a3 to fffff800030d2c00

STACK_TEXT: 
fffff880`07cac928 fffff800`0314f5a3 : 00000000`00000050 fffff910`c0e0b750 00000000`00000000 fffff880`07caca90 : nt!KeBugCheckEx
fffff880`07cac930 fffff800`030d0d2e : 00000000`00000000 fffff910`c0e0b750 00000000`00000000 fffff900`c0e0b690 : nt! ?? ::FNODOBFM::`string'+0x43801
fffff880`07caca90 fffff960`00185750 : fffff960`00164a37 00000000`00000000 00000000`76b575d4 00000000`00000000 : nt!KiPageFault+0x16e
fffff880`07cacc28 fffff960`00164a37 : 00000000`00000000 00000000`76b575d4 00000000`00000000 00000000`00000020 : win32k!memmove+0x250
fffff880`07cacc30 fffff960`00164979 : 00000000`0000a918 fffffa80`0a0c7530 ffffffff`ffffffff 00000000`00000000 : win32k!CreateProp+0x87
fffff880`07cacc60 fffff960`001a2345 : 00000000`00000000 00000000`0000a918 00000000`00000000 00000000`0000000f : win32k!InternalSetProp+0x45
fffff880`07cacc90 fffff800`030d1e93 : fffffa80`0a0c7530 fffff880`07cacd40 00000000`00000000 00000000`00000000 : win32k!NtUserSetProp+0xe1
fffff880`07caccc0 00000000`76b56fba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`03b2de98 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76b56fba


STACK_COMMAND:  kb

FOLLOWUP_IP:
win32k!memmove+250
fffff960`00185750 488b440af8      mov     rax,qword ptr [rdx+rcx-8]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  win32k!memmove+250

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: win32k

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4fd6b298

FAILURE_BUCKET_ID:  X64_0x50_win32k!memmove+250

BUCKET_ID:  X64_0x50_win32k!memmove+250

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

[AgentFXA]

Yep, do few ram tests with memtest86+ (at least 2 iterations)  - if flawless the CPU (mem controller) is the culprit. All provided your machine is not screwed by overclocking in any way.

[dirtydan]

No overclocking. It's very frustrating, the machine will run flawlessly for a month, zero changes then bam BSOD when doing nothing in particular.

It is a two year old OS install with a lot of software, time for a wipe.

[DarkstaR]

Yes why not wiping ? But it could be maybe a psu problem even though your corsair is a good model it may be a little bit old now and could be faulty: low +12v range as you should know that the x4 970 be draws more power than your "light"  x3 450