Troubleshooting 0x4E PFN_LIST_CORRUPT

The Debugging Tools for Windows are required to analyze crash dump files. If you do not have the Debugging Tools for Windows installed or dump files are not being generated on system crash, see this post for installation/configuration instructions:

http://mikemstech.blogspot.com/2011/11/windows-crash-dump-analysis.html

0x0000004E PFN_LIST_CORRUPT is a fairly common bug check (blue screen of death) on the Windows platform (Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, and Windows 8). This indicates that there was corruption with the page frame number list (PFN) or a page table entry (PTE). These are two important lists in the Windows memory manager that help keep track of pages in a process' virtual address space that are placed on disk.

For the vast majority of people, PFN_LIST_CORRUPT occurs in one of two cases: A badly designed/developed driver is corrupting the system state or there are hardware problems with the physical memory (RAM) or hard drive. Analysis of this bug check from a minidump doesn't typically yield results because the specific driver call that corrupted the running system state has long since passed and the error is detected by the kernel when it is encountered by the memory manager in Windows (often leaving the NT Kernel [ntoskrnl.exe, ntkrnlpa.exe, ntkrnlmp.exe, and ntkrnlpamp.exe] as the faulting module in the crash dump). This is typical with parameter 1 equal to 0x01, 0x02, 0x8F, and 0x99, or other unknown/undocumented values for parameter 1. A virus or other malware may also cause this corruption.

On occasion, the faulting driver might be in the stack trace (use !analyze -v, or any of the k commands [kb, kv, etc.]). This is typical when parameter 1 = 0x07 or 0x9E.

For completeness, a dump is illustrated below,

3: 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: 0000000000099cdb, page frame number
Arg3: 0000000000000005, current page state
Arg4: 0000000000000000, 0

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


BUGCHECK_STR:  0x4E_99

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  witcher2.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80003117d7c to fffff8000308ec40

STACK_TEXT:  
... : nt!KeBugCheckEx
... : nt!MiBadShareCount+0x4c
... : nt! ?? ::FNODOBFM::`string'+0x333ca
... : nt!MiDeleteAddressesInWorkingSet+0x307
... : nt!MmCleanProcessAddressSpace+0x96
... : nt!PspExitThread+0x56a
... : nt!PsExitSpecialApc+0x1d
... : nt!KiDeliverApc+0x2ca
... : nt!KiInitiateUserApc+0x70
... : nt!KiSystemServiceExit+0x9c
... : 0x74b82e09


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiBadShareCount+4c
fffff800`03117d7c cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!MiBadShareCount+4c

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0x4E_99_nt!MiBadShareCount+4c

BUCKET_ID:  X64_0x4E_99_nt!MiBadShareCount+4c

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

Troubleshooting this error involves testing the RAM and identifying possible issues with the hard drive using vendor supplied diagnostic utilities or looking at the SMART statistics. If a hardware issue is identified, the failing component should be replaced (in the case of a hard drive, it may be desirable to rescue the data to a flash drive or other external hard drive).  Once a hardware issue is ruled out, the next stage is to try to identify the corrupting driver by enabling driver verifier (and looking at the associated verifier-enabled memory dumps). If any file corruption exists with critical system files, it may be necessary to check the filesystem and repair the damaged files offline.

See Also
Windows Crash Dump Analysis