BSOD MEMORY_MANAGEMENT in Vista x64

**rifters** · September 29, 2007

Hi, my PC with Vista x64 has started firing off BSOD's. Namely MEMORY_MANAGEMENT about once maybe twice a day, and occasionally the IRQ_NOT_EQUAL BSOD aswell.

This PC has had Vista x64 installed for appx 3 months. During the first couple of months the system ran fine, no BSOD's or anything. Then all of a sudden, out of the blue, with no hardware changes, these BSOD problems have appeared.

I've just completed a clean reinstall yesterday to see if it goes away, and today, once again, a MEMORY_MANAGEMENT BSOD.

The OS is a fully updated Vista x64 OEM activated version. No hardware has been changed since the initial install and activation.

Spec fwiw:

Core 2 Duo E6600 @ 3GHz (334x9)

4 GB OCZ DDR2 @ 502MHz

Abit IP35 Pro P35 Motherboard

EVGA 8800 Ultra PCIE VGA

X-FI Extreme Gamer PCI Soundcard

Hauppauge DVB-t-500 Dual DVB Tuner PCI card

700w Seasonic PSU

CPU, case etc all well cooled with third part performance parts.

I'm 99 percent sure hardware wise the system is stable - again - this ran fine for just over 2 months like this with no BSOD's.

I've tried various different drivers, some beta, some final & certified. The problem is the same throughout. The BSOD's aren't occuring in anything specific either. For example not under a heavy gaming load, or a large download. The last one occured whilst simply opening IE7 from the desktop. Vista reports appx 1GB physical is in use once the OS has loaded. Using Orthos in blend mode, there are no errors or other problems with either memory or CPU under load either. The page file is set to auto managed by Vista.

I've just downloaded the debugger kit for x64, after reading this thread http://www.msfn.org/board/Creating_memory_dumps_t90244.html, but before I go on, does that process work in Vista x64?

Can anybody shed some light on this?

Thanks in advance.

-Rifters

**Batfinks** · September 29, 2007

Am having exact same issue myself, for months my systems been perfectly fine then recently getting BSOD due to "MEMORY_MANAGEMENT" or "IRQ_NOT_EQUAL"

have tested my memory each stick for over 22hrs total running memtest and both sticks pass flawlessly.

all drivers are latest and working error free to my knowledge.

oh before i forget am Running Vista Business 32bit OEM (original and activated)

my system specs are:

Intel E6600

Asus P5W DH DLX/Wifi-Ap

2x1gig Corsair XMS2 800MHz DDr2

BFG 8800GTOC

Maxtor sata2 300gig *primary* (AHCI mode)

WD sata2 500gig (aaks model) *file storage* (AHCI mode)

sony dvdrw x18sp.

Coolmaster stacker case.

580w HiperX

Another possibly related issue is this:

now this is strange so read carefully:

on cold boot my system will boot into vista fine, once i do the usual cache cleaning/disk cleanup/ Defender scan my system will BSOD !!!

the EXACT same thing will happen if i switch my system off and unplug it from the wall for over 10mins !!

but once that first BSOD has happened it doesn't happen again, any help here ?

thought it could be my PSU at first but tested and working perfectly fine and it doesn't ever happen in Xp.

Edited September 30, 2007 by Batfinks

**cluberti** · September 30, 2007

First off, neither of those messages are speaking to the RAM in your machine, they're talking about VIRTUAL memory (kernel mode address space, to be exact) and the IRQL of a driver. This is almost always caused by a bad driver, so getting a dump of the problem for us to analyze would help out a lot.

**rifters** · September 30, 2007

The process I linked to in my previous post about creating dumps does not work correctly for me in Vista x64. I followed the instructions re. creating registry keys, then rebooted, pressing right ctrl and scroll twice does nothing. In system properties > start up and recovery > write debugging information is set to kernel memory dump. The only other two options here are <none> and small memory dump, this is despite performing the steps in the link in my previous post. Thus, all I have been able to get into the debugger are these two minidump examples:

#1

1: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

MEMORY_MANAGEMENT (1a)

# Any other values for parameter 1 must be individually examined.

Arguments:

Arg1: 0000000000041790, The subtype of the bugcheck.

Arg2: fffffa800310c440

Arg3: 000000000000ffff

Arg4: 0000000000000000

Debugging Details:

------------------

BUGCHECK_STR: 0x1a_41790

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: iexplore.exe

CURRENT_IRQL: 0

BAD_PAGES_DETECTED: d

LAST_CONTROL_TRANSFER: from fffff80002870749 to fffff8000284dbd0

STACK_TEXT:

fffff980`3fccfa88 fffff800`02870749 : 00000000`0000001a 00000000`00041790 fffffa80`0310c440 00000000`0000ffff : nt!KeBugCheckEx

fffff980`3fccfa90 fffff800`0288d52a : 00000000`00000011 00000000`0f4bafff 00000000`00000000 fffffa80`00000000 : nt!MiDeleteVirtualAddresses+0xd49

fffff980`3fccfc20 fffff800`0284d673 : ffffffff`ffffffff fffffa80`095bbad0 00000000`00000001 fffffa80`00008000 : nt!NtFreeVirtualMemory+0x38a

fffff980`3fccfd20 fffff800`0284db80 : fffff960`000c34d8 00000000`0ee00000 00000000`00000004 00000000`00000001 : nt!KiSystemServiceCopyEnd+0x13

fffff980`3fccfeb8 fffff960`000c34d8 : 00000000`0ee00000 00000000`00000004 00000000`00000001 00000000`00000001 : nt!KiServiceLinkage

fffff980`3fccfec0 fffff960`000cb615 : 00000000`0ee00000 00000000`00000001 fffff900`c018d540 00000000`00000000 : win32k!SURFACE::bDeleteSurface+0x228

fffff980`3fccffa0 fffff960`000c2ed4 : 00000000`00000000 fffff980`3fcd0c00 fffff900`c07a3180 fffffa80`048794f0 : win32k!NtGdiCloseProcess+0x2d5

fffff980`3fcd0000 fffff960`000c251f : 00000000`00000000 fffff900`c07a3180 00000000`00000000 fffff900`c01e6460 : win32k!GdiProcessCallout+0x1f4

fffff980`3fcd0080 fffff800`02ab360e : fffffa80`07ca04f0 00000000`00000000 fffffa80`07ca04f0 fffffa80`095bbad0 : win32k!W32pProcessCallout+0x6f

fffff980`3fcd00b0 fffff800`02a6300d : fffffa80`000000ff 00000000`00000001 fffffa80`09a7f660 00000000`78457350 : nt!PspExitThread+0x29e

fffff980`3fcd0170 fffff800`02846049 : fffffa80`095bbad0 fffff980`3fcd0220 00000000`08d8d070 00000000`00000020 : nt!PsExitSpecialApc+0x1d

fffff980`3fcd01a0 fffff800`0285f9ea : 00000000`7ef82000 ffe7ebf6`ffe7ebf6 fffff800`02a63020 00000000`00000001 : nt!KiDeliverApc+0x409

fffff980`3fcd0240 fffff800`0284d71d : fffffa80`095bbad0 00000000`7ef82000 00000000`00000020 fffffa80`042e9b50 : nt!KiInitiateUserApc+0x7a

fffff980`3fcd0380 00000000`76fa1ff7 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0xa2

00000000`08d8e0b0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76fa1ff7

STACK_COMMAND: kb

SYMBOL_NAME: PAGE_NOT_ZERO_VISTA

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUCKET_ID: PAGE_NOT_ZERO_VISTA

Followup: MachineOwner

---------

*** Memory manager detected 13 instance(s) of page corruption, target is likely to have memory corruption.

#2

MEMORY_MANAGEMENT (1a)

# Any other values for parameter 1 must be individually examined.

Arguments:

Arg1: 0000000000041790, The subtype of the bugcheck.

Arg2: fffffa8003112080

Arg3: 000000000000ffff

Arg4: 0000000000000000

Debugging Details:

------------------

BUGCHECK_STR: 0x1a_41790

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: SearchProtocolH

CURRENT_IRQL: 0

BAD_PAGES_DETECTED: 2

LAST_CONTROL_TRANSFER: from fffff80002870749 to fffff8000284dbd0

STACK_TEXT:

fffff980`1bfff798 fffff800`02870749 : 00000000`0000001a 00000000`00041790 fffffa80`03112080 00000000`0000ffff : nt!KeBugCheckEx

fffff980`1bfff7a0 fffff800`02871e37 : fffffa80`036f9f11 00000000`0069dfff 00000000`00000000 fffff680`00000000 : nt!MiDeleteVirtualAddresses+0xd49

fffff980`1bfff930 fffff800`02880597 : fffffa80`054a1c10 00000000`00000000 fffffa80`054a1c10 fffffa80`078c3e60 : nt!MiRemoveMappedView+0x62b

fffff980`1bfffa60 fffff800`02ab3756 : fffff880`0576aaa0 00000000`00000000 00000000`00000000 fffffa80`04e208d0 : nt!MmCleanProcessAddressSpace+0x277

fffff980`1bfffab0 fffff800`02a85f9d : 00000000`00000000 fffffa80`04e20801 000007ff`fffdc000 00000000`00000000 : nt!PspExitThread+0x3e6

fffff980`1bfffb70 fffff800`02a8b93d : 00000000`00000000 00000000`0000000c 00000000`00187cb0 fffffa80`0000000c : nt!PspTerminateThreadByPointer+0x4d

fffff980`1bfffbc0 fffff800`0284d673 : fffffa80`054a1c10 fffffa80`04e208d0 fffff980`1bfffca0 00000000`00187cb0 : nt!NtTerminateProcess+0x18d

fffff980`1bfffc20 00000000`7765053a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13

00000000`000af9d8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7765053a

STACK_COMMAND: kb

SYMBOL_NAME: PAGE_NOT_ZERO_VISTA

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUCKET_ID: PAGE_NOT_ZERO_VISTA

Followup: MachineOwner

---------

*** Memory manager detected 2 instance(s) of page corruption, target is likely to have memory corruption.

One instance is the crash I referred to in my original post about IE7. The second module is unknown presumably because its a minidump.

-rifters

**cluberti** · September 30, 2007

Correct - however, we are doing work in win32k.sys when the crashes occur (win32k!SURFACE::bDeleteSurface+0x228), which would indicate a video card driver issue. What video card is in that machine, and what driver set are you running for that card?

I followed the instructions re. creating registry keys, then rebooted, pressing right ctrl and scroll twice does nothing.

First, you need a PS/2 keyboard attached for this to work (and you also need to reboot for the reg change to work). Second, since the machine is crashing on it's own, there's no need to do a keyboard dump - it'll crash dump on it's own every time it BSOD's.

In system properties > start up and recovery > write debugging information is set to kernel memory dump. The only other two options here are <none> and small memory dump, this is despite performing the steps in the link in my previous post.

If you set the registry key for CrashDumpEnabled to 1 and reboot, the option for a complete memory dump will NOT be seen in the GUI - however, it'll still do a complete crash dump because the CrashDumpEnabled value is 1. If you go into the GUI and click OK, it'll reset that to whatever was in the box - so, set CrashDumpEnabled to 1, make sure the page file on your C: drive is RAM+50MB or so, and reboot. Don't go back and check anything, just leave it as-is . The next time you get a memory dump from a BSOD, it'll be a complete dump.

**RJARRRPCGP** · September 30, 2007

"IRQL_NOT_LESS_OR_EQUAL" is often caused by an unstable processor overclock. It can be caused by not having enough Vcore.

You need to get Prime95 to confirm that your Core 2 Duo is stable.

Edited September 30, 2007 by RJARRRPCGP

**rifters** · October 2, 2007

>we are doing work in win32k.sys when the crashes occur (win32k!SURFACE::bDeleteSurface+0x228), which would indicate a video card driver issue

I see the line you mention in the first dump, but what about the second one? (the blue one) I don't see the same line there. Its an nvidia geforce 8800 ultra running 163.69 (certified offiicial latest), have also tried 162.18's.

I've applied the changes to page file etc, will wait and see, curiously Windows recommended a page file of 6 GB so I set it to that (it was previously at 4.3GB) and so far theres only been 1 crash since my last post here, a few minutes ago infact, unfortunatley though when I tried to open it in the debugger it would not load for some reason (used the same process for the other 2 debugs). I wasn't at the screen when the BSOD came so didn't see the message. Will post back if\when I can do another debug process with new dump files.

>You need to get Prime95 to confirm that your Core 2 Duo is stable.

As I said in my original post I'm 99 percent sure the hardware is stable. The Orthos test I mention is prime95 with a GUI. I run 2 instances of this test in blend mode on each core, which stress tests CPU and memory at the same time, for 24 hours continuous, the system doesn't break a sweat. Core 2 Duos are notoriously good overclockers @ default V's. Plus I have all thermal throttling enabled in the BIOS which lowers the multiplier at idle and light loads - the same time all these BSOD's occur.

-rifters

Edited October 2, 2007 by rifters

**cluberti** · October 2, 2007

The drivers for that particular card and x64 vista don't get along well, so I'm not surprised here. The blue dump you posted seems to be removing a mapped view of a section in memory during a thread termination in kernel, which means it's likely this was a kernel mode driver thread. Hard to say without a dump, so if you can get one and post it somewhere I can get to it, I can help further.

**RJARRRPCGP** · October 3, 2007

The Orthos test I mention is prime95 with a GUI. I run 2 instances of this test in blend mode on each core, which stress tests CPU and memory at the same time, for 24 hours continuous, the system doesn't break a sweat. Core 2 Duos are notoriously good overclockers @ default V's. Plus I have all thermal throttling enabled in the BIOS which lowers the multiplier at idle and light loads - the same time all these BSOD's occur.

Yeah, I knew that already and if it was going for 24 hours, you're good to go.

**epm999** · October 17, 2007

I have the same problem:

From what I can tell is that during the bootup a (as yet unnamed) kernel mode driver is corrupting nonpaged pool.

This caused the other driver(s) to crash when it reads it nonpaged pool.

I have not been able to repro the problem more than one time a day (cold boot in the morining)

I can provide hardware details if you wish, but i do see that we have the graphics card (and driver) in

common so I am going to focus on them for the time being.

Let me know if you can find a faster repro method.

Anyone have an Idea why it only happens one time a day? (only the first cold boot

warm boots and further cold boots seem ok)

thanks

jb

**cluberti** · October 18, 2007

I could guess, but I'd rather see a dump file to analyze. Can you configure your box for a complete dump and provide that the next time it occurs?

**epm999** · October 18, 2007

Hi, I looked into this some more and have done the following:

- found that I get the problem on all cold boots if I turn off power at the power supply for 10 mins

- Disabled the nvidia driver so that I am only running the OS provided VGA drivers

here some of the current crash dump info and a dump threads running on each processor

I had verifier and gflags set to check for pool corruption and to bugcheck on exception.

Sorry about the lack of debugging its been over 10 years since I used a debugger.

I also have the full crash dump file if that is really what you wanted.

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

PFN_LIST_CORRUPT (4e)

Typically caused by drivers passing bad memory descriptor lists (ie: calling

MmUnlockPages twice with the same list, etc). If a kernel debugger is

available get the stack trace.

Arguments:

Arg1: 0000000000000099, A PTE or PFN is corrupt

Arg2: 00000000001062e0, page frame number

Arg3: 0000000000000002, current page state

Arg4: 00000000001068df, 0

Debugging Details:

------------------

Page dca58 not present in the dump file. Type ".hh dbgerr004" for details

Page dcd25 not present in the dump file. Type ".hh dbgerr004" for details

BUGCHECK_STR: 0x4E_99

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff800018c30db to fffff8000184dbd0

STACK_TEXT:

fffff980`0a729218 fffff800`018c30db : 00000000`0000004e 00000000`00000099 00000000`001062e0 00000000`00000002 : nt!KeBugCheckEx

fffff980`0a729220 fffff800`0187c05b : fffffa80`00000000 fffff700`0008acf0 00000000`0000139c 00000000`00022401 : nt!MiBadShareCount+0x4b

fffff980`0a729260 fffff800`018824e5 : fffffa80`06cb12a0 3a100000`d9680000 00000003`0000139c 00000000`00000051 : nt!MiDeletePfnList+0x3fb

fffff980`0a7292f0 fffff800`0188040e : fffffa80`06cb12a0 00000000`00000a73 fffffa80`0000000e 00000000`00000001 : nt!MiDeleteAddressesInWorkingSet+0x2f8

fffff980`0a729ba0 fffff800`01ab3756 : fffffa80`03e55c50 00000000`c0000005 00000000`00000000 fffffa80`78457350 : nt!MmCleanProcessAddressSpace+0xee

fffff980`0a729bf0 fffff800`01a85f9d : fffffa80`c0000005 fffffa80`0407b301 000007ff`fffa8000 00000000`c0000005 : nt!PspExitThread+0x3e6

fffff980`0a729cb0 fffff800`01a8b93d : 00000000`00000000 00000000`0000000a fffff980`0a72ac20 00000000`0000000a : nt!PspTerminateThreadByPointer+0x4d

fffff980`0a729d00 fffff800`0184d673 : fffffa80`06cb12a0 fffffa80`0407b370 fffff980`0a729de0 fffff980`0a72ac20 : nt!NtTerminateProcess+0x18d

fffff980`0a729d60 fffff800`0184db80 : fffff800`018babec fffff980`0a72a540 fffff980`0a72aca0 fffff980`0a72ac20 : nt!KiSystemServiceCopyEnd+0x13

fffff980`0a729ef8 fffff800`018babec : fffff980`0a72a540 fffff980`0a72aca0 fffff980`0a72ac20 00000000`00000030 : nt!KiServiceLinkage

fffff980`0a729f00 fffff800`018fce61 : fffff980`0a72a540 fffff980`0a72a540 fffff980`0a72ac20 00000000`02e0e001 : nt! ?? ::FNODOBFM::`string'+0x1280c

fffff980`0a72a500 fffff800`018521a5 : fffff980`0a72a540 fffff980`0a72a5e0 fffffa80`0407b370 00000000`00000000 : nt!KiRaiseException+0x141

fffff980`0a72aae0 fffff800`0184d673 : 00000000`00000008 00000000`00000000 00000000`00000001 fffffa80`03fc3b60 : nt!NtRaiseException+0x85

fffff980`0a72ac20 00000000`77bf4f30 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13

00000000`02e0dfa8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77bf4f30

STACK_COMMAND: kb

FOLLOWUP_IP:

nt!MiBadShareCount+4b

fffff800`018c30db cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!MiBadShareCount+4b

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 46830f41

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: X64_0x4E_99_nt!MiBadShareCount+4b

BUCKET_ID: X64_0x4E_99_nt!MiBadShareCount+4b

Followup: MachineOwner

---------

0: kd> !pfn 1062e0

PFN 001062E0 at address FFFFFA8003128A00

flink 001064E1 blink / share count 001068DF pteaddress FFFFF88000781808

reference count 0000 used entry count 0000 Cached color 0 Priority 5

restore pte FA80061BA43004C0 containing page 107A67 Standby P

Shared

0: kd> !process 0 7

Here are some of the running processes (one for each cpu)

THREAD fffffa8007071bb0 Cid 0004.03ac Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 3

Not impersonating

DeviceMap fffff88000007820

Owning Process fffffa8003697430 Image: System

Wait Start TickCount 29875 Ticks: 0

Context Switch Count 342

UserTime 00:00:00.000

KernelTime 00:00:00.015

Win32 Start Address nt!PfTLoggingWorker (0xfffff80001bcee10)

Stack Init fffff98004b63db0 Current fffff98004b639d0

Base fffff98004b64000 Limit fffff98004b5e000 Call 0

Priority 13 BasePriority 7 PriorityDecrement 6 IoPriority 2 PagePriority 5

Child-SP RetAddr : Args to Child : Call Site

fffff980`04b63af0 fffff800`01b4171c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!PfTAcquireLogEntry+0xb

fffff980`04b63b00 fffff800`01b92642 : fffffa80`0596f000 fffffa80`00000400 fffff980`04b63ba0 fffffa80`053bbf80 : nt!PfpLogPageAccess+0x1ee

fffff980`04b63b70 fffff800`01bceef0 : fffffa80`07071b01 00000000`00000080 fffff800`019542c8 00000000`00000000 : nt!PfpFlushBuffers+0x1a2

fffff980`04b63c20 fffff800`01ae279b : ffffffff`ff676980 fffffa80`07071bb0 fffff980`0ba8b6c0 00000000`00461901 : nt!PfTLoggingWorker+0xe0

fffff980`04b63d50 fffff800`018344f6 : fffff980`00c98180 fffffa80`07071bb0 fffff980`00ca1c40 fffff980`014e8ce0 : nt!PspSystemThreadStartup+0x5b

fffff980`04b63d80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

THREAD fffffa800407b370 Cid 0270.02c0 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 0

Not impersonating

DeviceMap fffff88001981cb0

Owning Process fffffa8006cb12a0 Image: svchost.exe

Wait Start TickCount 29875 Ticks: 0

Context Switch Count 42

UserTime 00:00:00.000

KernelTime 00:00:00.000

Win32 Start Address 0x000007fefb585000

Stack Init fffff9800a72adb0 Current fffff9800a728990

Base fffff9800a72b000 Limit fffff9800a725000 Call 0

Priority 10 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5