Arguments of MEMORY_MANAGEMENT (1a) Bugcheck

Hi,

does someone know the meaning of the MEMORY_MANAGEMENT (1a) bugcheck arguments? The first is explained in WinDbg help, but what do the others mean? This is what i got:

MEMORY_MANAGEMENT (1a)

Any other values for parameter 1 must be individually examined.

Arguments:
Arg1: 00041284, A PTE or the working set list is corrupt.
Arg2: 00d0e001
Arg3: 00000000
Arg4: c0503000

Debugging Details:

BUGCHECK_STR: 0x1a_41284

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 80525056 to 80533846

STACK_TEXT:
f48e0a00 80525056 0000001a 00041284 00d0e001 nt!KeBugCheckEx+0x1b
f48e0a38 80535ca2 00000000 c0003438 81ce1da0 nt!MiLocateWsle+0xc0
f48e0a50 805f34b8 c0003438 810f0590 81ce1f98 nt!MiRemovePageFromWorkingSet+0x23
f48e0ae4 805efa26 81ce1da0 f48e0b4c f48e0b40 nt!MiProtectVirtualMemory+0x3c5
f48e0c20 804de7ec ffffffff f48e0cf8 00000000 nt!NtAllocateVirtualMemory+0x306
f48e0c20 804dc821 ffffffff f48e0cf8 00000000 nt!KiFastCallEntry+0xf8
f48e0cb0 804f794e ffffffff f48e0cf8 00000000 nt!ZwAllocateVirtualMemory+0x11
f48e0d14 804e9b55 00d0feac 0009f198 00d0fed8 nt!MiCheckForUserStackOverflow+0xc6
f48e0d4c 804e172b 00000000 00d0feac 00000001 nt!MmAccessFault+0xbb6
f48e0d4c 7c91e514 00000000 00d0feac 00000001 nt!KiTrap0E+0xcc

My first assumption was some bad RAM, then made a full check on the RAM with memory diagnostics and memcheck86. Both displayed no errors after full run. Then i run chkdsk on the drives holding the pagefiles. Both seem to be error free regarding chkdsk. What else could have lead to this? CPU, Mainboard? Maybe a bit flip due to a severe ram damage somewhere that only happens after some time and other memtests cant find? But i am more interested in the meaning of the parameters, so i can understand the bugcheck in detail.

00d0e001 is a virtual address, apparently from a user stack. Its PTE is valid and the code below is trying to make it a new guard page for the stack, which requires removing it from the working set of the process. The problem is that the working set has no valid entry for this VA, thus the bugcheck.

Is this reproducible? If not then the most likely reason is a random corruption (e.g. a bit flip) in the working set list.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@arcor.de
Sent: Thursday, April 12, 2012 7:06 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Arguments of MEMORY_MANAGEMENT (1a) Bugcheck

Hi,

does someone know the meaning of the MEMORY_MANAGEMENT (1a) bugcheck arguments? The first is explained in WinDbg help, but what do the others mean? This is what i got:

MEMORY_MANAGEMENT (1a)

Any other values for parameter 1 must be individually examined.

Arguments:
Arg1: 00041284, A PTE or the working set list is corrupt.
Arg2: 00d0e001
Arg3: 00000000
Arg4: c0503000

f48e0a00 80525056 0000001a 00041284 00d0e001 nt!KeBugCheckEx+0x1b
f48e0a38 80535ca2 00000000 c0003438 81ce1da0 nt!MiLocateWsle+0xc0
f48e0a50 805f34b8 c0003438 810f0590 81ce1f98 nt!MiRemovePageFromWorkingSet+0x23
f48e0ae4 805efa26 81ce1da0 f48e0b4c f48e0b40 nt!MiProtectVirtualMemory+0x3c5
f48e0c20 804de7ec ffffffff f48e0cf8 00000000 nt!NtAllocateVirtualMemory+0x306
f48e0c20 804dc821 ffffffff f48e0cf8 00000000 nt!KiFastCallEntry+0xf8
f48e0cb0 804f794e ffffffff f48e0cf8 00000000 nt!ZwAllocateVirtualMemory+0x11
f48e0d14 804e9b55 00d0feac 0009f198 00d0fed8 nt!MiCheckForUserStackOverflow+0xc6
f48e0d4c 804e172b 00000000 00d0feac 00000001 nt!MmAccessFault+0xbb6 f48e0d4c 7c91e514 00000000 00d0feac 00000001 nt!KiTrap0E+0xcc

Ok, thanks for the detailed description.

>Is this reproducible?

No, not yet, at least so far. Seems like the thing you said with the flipped bit.

I’ve had RAM gone sour on me. Twice. Those were brand-name DIMM, from the last American DRAM manufacturer. First, the memory test found bit errors one one DIMM; I chucked it and ran for a few months on a single DIMM. Then the system started crashing again, and the test was showing bit errors on the second DIMM.

In both cases the errors were showing in a limited range of physical addresses, and the same bit of the QWORD. This means they were caused by real deterioration of memory column line. Or the cell in the reference row.

> I’ve had RAM gone sour on me. Twice. Those were brand-name DIMM

Once I had a single bit flip bug on an operation which involved 50GB of data.

After playing with it a while, I just did “fc /b” of my data file and its copy, and… it found corrupt bytes.

Only after this I’ve run Vista’s MEMCHECK which was just plain hung :slight_smile:

Reducing the frontside bus frequency from 800 MHz to 667 was the solution.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com