[Solved] BSOD PFN_LIST_CORRUPT 64-bit

Okay, so for a while on Windows 7 64-bit I've been getting this blue screen

PFN_LIST_CORRUPT

0x0000004E

And Microsoft has not been able to tell me how I can fix it, they have solutions but none of them work.

Any Ideas?

Memory I've used them for 3 years and they've all run cold as heck with no problems, until I installed Windows 7. They are Corsair Dominators DDR2 800Mhz and are for sure D9's as they are V1.1 They are running at 2.1Volts like it asks.

memtest says it passes. I ran it a few days ago for 18+ hours. and multiple times with single sticks before that trying all the slots.

Reply to Gin Fushicho

no wonder microsoft couldn't help you. you were trying to get help with an OS that hasn't even been released yet

Reply to captaincharisma

Best answer

From: http://www.osronline.com/article.cfm?article=334

Quote :

Bugchecks Explained: PFN_LIST_CORRUPT
OSR Staff | Published: 24-Aug-04| Modified: 24-Aug-04

What Happened?

Windows tracks physical pages of memory using a table called the Page Frame Database. This database (which actually is just a big one-dimensional array) is indexed by physical page number. As a result, the page frame database is typically referred to as the Page Frame Number list or PFN.

Every page of physical memory has an associated PFN entry. Each PFN entry contains information about the state of its corresponding physical page in the system. This state includes information about whether the corresponding physical page is in use, how it’s being used, a count of active users of the page, and a count of pending I/O operations on the page.

Depending on the pages state, a PFN entry may be on one of several lists that the Memory Manager maintains. The listheads for these lists are simple global variables that are used for quick access to PFN entries of certain types. For example, one such list would be the list that contains all the modified pages that need to be written to disk.

Because all the PFN lists and entries are present in the high half of kernel virtual address space, they are subject to corruption through stray pointer accesses (such as by errant drivers or other similar kernel-mode modules). Also, the count in the PFN that tracks the number of I/O related accesses to a given physical page can be corrupted by improper MDL handling.

Whenever Windows detects that any of the PFN lists or any of the PFN entries themselves have become invalid, the system halts with a PFN_LIST_CORRUPT bugcheck.

Who Did It?

This bugcheck usually occurs for one of two reasons, the first reason being memory corruption. If there is a buggy driver in the system that is writing on memory that it does not own, it could easily corrupt one of the PFN lists or entries. In order to rule this out, you should run Driver Verifier with Special Pool enabled for suspect drivers in the system. This will hopefully allow you to catch the misbehaving driver in the act of scribbling memory, instead of receiving a crash sometime later when the O/S discovers the damage.

The second cause for this bugcheck is incorrect MDL handling. For example, one use of MDLs is to allow you to "lock" the physical memory that backs a virtual address range so that the memory stays resident while your driver is accessing it. This is achieved by using the MmProbeAndLockPages DDI. One of the things that this DDI does is take out a reference on the PFN entries of the underlying physical pages, ensuring that the Memory Manager does not page them out. The corresponding DDI to undo this operation, MmUnlockPages, is responsible for decrementing the reference counts taken out in the previous call. If a driver happens to call MmUnlockPages too many times on an MDL, the reference count on the underlying PFN entries could drop to below zero (to 0xFFFFFFFF). The system considers this to be a critical error, as one or more of the PFN entries is obviously invalid. Therefore, this bugcheck will occur.

If your driver or a driver in your stack is being blamed for a PFN_LIST_CORRUPT bugcheck, go over your code and make sure that you are properly handling your MDLs . Remember that even if you do not create or destroy any MDLs directly, you play a part in the creation and destruction of them if you handle IRPs whose buffers are described with DIRECT_IO. Driver Verifier and the checked build of Windows can help pinpoint IRP and MDL handling errors.

How Should I Fix It?

How this is fixed varies depending on the reason of the bugcheck. Using Driver Verifier and the checked build of the O/S should allow you to pinpoint the driver that is either corrupting memory or mishandling MDLs. If the offending driver is not a driver that you have any control over, the only available option is disabling the driver until a fixed version is available.

Related WinDBG Commands

· !memusage

· !pfn

Related O/S Structures

· nt!_MMPFN

· nt!_MMPFNENTRY

· nt!_MMPFNLIST

Related O/S Variables

· nt!MmBadPageListHead

· nt!MmStandbyPageListHead

· nt!MmModifiedNoWritePageListHead

· nt!MmModifiedPageListHead

· nt!MmFreePageListHead

· nt!MmZeroedPageListHead

· nt!MmRomPageListHead

Message quoted 1 times

------------------------------ Trying to make up his mind whether the current situation is due to an overabundance of high quality pharmaceuticals freely available on the Internet. ...or not enough of them.
Reply to Scotteq

Since you say the physical memory passes a thorough memtest check, the next logical place to check is Drivers - If one is passing invalid memory references, then that could be causing your error.

------------------------------ Trying to make up his mind whether the current situation is due to an overabundance of high quality pharmaceuticals freely available on the Internet. ...or not enough of them.
Reply to Scotteq

@_@ That was a lot to learn all at once. But now i'm running driver verifier which took me a sec to realize i need the command window.

Edit: The driver verifier made my windows blue screen with only this.

0x000000CD

Message edited by Gin Fushicho on 07-14-2009 at 05:58:42 PM

Reply to Gin Fushicho

Back to basics then - Unplug everything that isn't necessary. If the problem goes away, then you know it's the fault of something you removed...

------------------------------ Trying to make up his mind whether the current situation is due to an overabundance of high quality pharmaceuticals freely available on the Internet. ...or not enough of them.
Reply to Scotteq

I've done that too. >.< Only thing I havnt un-plugged is my video card, and I got the supposed Win 7 64-bit drivers for it.

Reply to Gin Fushicho

The remove your video drivers, and replace them. See does that work.

------------------------------ Trying to make up his mind whether the current situation is due to an overabundance of high quality pharmaceuticals freely available on the Internet. ...or not enough of them.
Reply to Scotteq

What should I replace them with? currently the ones I have are the only Win 7 drivers. >.<

Reply to Gin Fushicho

You can download them from your card's maker. ATI releases monthly - and there are at least a half dozen versions of their drivers for Win 7. nVidia have been doing updates every couple months..

ATI: http://game.amd.com/us-en/drivers_catalyst.aspx

nVidia: http://game.amd.com/us-en/drivers_catalyst.aspx

There are also 3rd perty sites - like Download.com - who keep older versions.

Message edited by Scotteq on 07-14-2009 at 09:18:43 PM

------------------------------ Trying to make up his mind whether the current situation is due to an overabundance of high quality pharmaceuticals freely available on the Internet. ...or not enough of them.
Reply to Scotteq

Maybe I should download an older Nvidia driver for windows 7 then. ^^;

Thank you

Message edited by Gin Fushicho on 07-14-2009 at 10:40:56 PM

Reply to Gin Fushicho

I just received this BSOD on my computer for the first time.

For me it occured when I attempted to shut off my second monitor using the screen resolution window in Windows 7. By doing it on the second monitor (the one that I was attempting to disable) it caused this BSOD.

Once I rebooted from the BSOD and shut off the 2ndary monitor using the primary monitor the error has not occured since. I regularly turn on or off my 2ndary monitor as I only need it for real life work, and this is the first time that I've ever tried to disable it from the 2ndary monitor, I have always shut off the 2nd monitor doing it on the primary monitor and never had an issue until I tried to shut it off on the 2nd monitor. The other thing that could cause this is the way that I have the monitors plugged into the computer, you see when I boot up windows, the boot up from bios and up until the "Welcome" message from Windows appears on my 2nd monitor, once Windows has taken over everything goes to my primary monitor, which makes me believe that I've just got the monitors plugged in to the wrong port on the video card, reverse them and everything should always come out on the primary monitor, one day I'll likely switch them around to be sure and to avoid having to have on my 2ndary monitor when ever I boot.

This would lead me to believe that there is something wonky in the Nvidia drivers that may cause this, but not such a big deal to me to have to downgrade the drivers and would rather just wait for any new drivers that Nvidia comes out with next.

While I love Windows 7 much more than XP, I do have to say that it produces more BSOD than XP ever did on my computers, in fact on all the computers that I have ever owned and had XP on, they all combined didn't produce as many BSOD that windows 7 produces, although in all fairness, Win 7 has been pretty solid just occasionally it tosses up a BSOD when trying to do something in an unconventional way. At least that has been my experience with it.

And in double fairness, although my installation of 7 is fresh and clean and is legitimate, for some reason it will not install .msi packages, it just ties up computer CPU time indefinitely, to where I have to just reboot and don't bother installing that .msi package which was probably just an optional component that I wanted to install anyway. Not worth my time to reinstall 7 and all the programs all over again until such a time as there is some crucial .msi program that I need to install I suppose.

Sorry for necro thread, just wanted to add why this BSOD happened on my computer in case it helps anybody else that gets it and wants to investigate it further.

Message quoted 1 times
Message edited by Jalida on 08-20-2010 at 11:57:16 PM

Reply to Jalida

Jalida wrote :

I just received this BSOD on my computer for the first time.

Sorry for necro thread, just wanted to add why this BSOD happened on my computer in case it helps anybody else that gets it and wants to investigate it further.

I'll tell you right now what fixed this for me and solved all my BSOD's, I had Corsair replace my RAM. All of it. I have not had a single BSOD since.

------------------------------ "Never skimp out on what everything else plugs into"
Reply to Gin Fushicho

Scotteq wrote :

From: http://www.osronline.com/article.cfm?article=334

Quote :

Bugchecks Explained: PFN_LIST_CORRUPT
OSR Staff | Published: 24-Aug-04| Modified: 24-Aug-04

What Happened?

Windows tracks physical pages of memory using a table called the Page Frame Database. This database (which actually is just a big one-dimensional array) is indexed by physical page number. As a result, the page frame database is typically referred to as the Page Frame Number list or PFN.

Every page of physical memory has an associated PFN entry. Each PFN entry contains information about the state of its corresponding physical page in the system. This state includes information about whether the corresponding physical page is in use, how it’s being used, a count of active users of the page, and a count of pending I/O operations on the page.

Depending on the pages state, a PFN entry may be on one of several lists that the Memory Manager maintains. The listheads for these lists are simple global variables that are used for quick access to PFN entries of certain types. For example, one such list would be the list that contains all the modified pages that need to be written to disk.

Because all the PFN lists and entries are present in the high half of kernel virtual address space, they are subject to corruption through stray pointer accesses (such as by errant drivers or other similar kernel-mode modules). Also, the count in the PFN that tracks the number of I/O related accesses to a given physical page can be corrupted by improper MDL handling.

Whenever Windows detects that any of the PFN lists or any of the PFN entries themselves have become invalid, the system halts with a PFN_LIST_CORRUPT bugcheck.

Who Did It?

This bugcheck usually occurs for one of two reasons, the first reason being memory corruption. If there is a buggy driver in the system that is writing on memory that it does not own, it could easily corrupt one of the PFN lists or entries. In order to rule this out, you should run Driver Verifier with Special Pool enabled for suspect drivers in the system. This will hopefully allow you to catch the misbehaving driver in the act of scribbling memory, instead of receiving a crash sometime later when the O/S discovers the damage.

The second cause for this bugcheck is incorrect MDL handling. For example, one use of MDLs is to allow you to "lock" the physical memory that backs a virtual address range so that the memory stays resident while your driver is accessing it. This is achieved by using the MmProbeAndLockPages DDI. One of the things that this DDI does is take out a reference on the PFN entries of the underlying physical pages, ensuring that the Memory Manager does not page them out. The corresponding DDI to undo this operation, MmUnlockPages, is responsible for decrementing the reference counts taken out in the previous call. If a driver happens to call MmUnlockPages too many times on an MDL, the reference count on the underlying PFN entries could drop to below zero (to 0xFFFFFFFF). The system considers this to be a critical error, as one or more of the PFN entries is obviously invalid. Therefore, this bugcheck will occur.

If your driver or a driver in your stack is being blamed for a PFN_LIST_CORRUPT bugcheck, go over your code and make sure that you are properly handling your MDLs . Remember that even if you do not create or destroy any MDLs directly, you play a part in the creation and destruction of them if you handle IRPs whose buffers are described with DIRECT_IO. Driver Verifier and the checked build of Windows can help pinpoint IRP and MDL handling errors.

How Should I Fix It?

How this is fixed varies depending on the reason of the bugcheck. Using Driver Verifier and the checked build of the O/S should allow you to pinpoint the driver that is either corrupting memory or mishandling MDLs. If the offending driver is not a driver that you have any control over, the only available option is disabling the driver until a fixed version is available.

Related WinDBG Commands

· !memusage

· !pfn

Related O/S Structures

· nt!_MMPFN

· nt!_MMPFNENTRY

· nt!_MMPFNLIST

Related O/S Variables

· nt!MmBadPageListHead

· nt!MmStandbyPageListHead

· nt!MmModifiedNoWritePageListHead

· nt!MmModifiedPageListHead

· nt!MmFreePageListHead

· nt!MmZeroedPageListHead

· nt!MmRomPageListHead

Thanks for trying to help but i have got no idea of what you're talking about or how to stop this error from recurring. My laptop is very new and i'm pretty worried. Can you please explain the solution to me in a a man's terms. Thank you.

Reply to fiddler07

This topic has been closed by Mousemonkey

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

http://www.st-owners.com/forums/images/smilies/bl11.gif

Reply to mousemonkey

[Solved] BSOD PFN_LIST_CORRUPT 64-bit

Forum Windows 7 : [Solved] BSOD PFN_LIST_CORRUPT 64-bit

General Discussion

Configuration & Customization

Drivers

Security

Please mind