PFN_LIST_CORRUPT

[Guest TC]

I have an x64 Vista Ultimate installation that is getting this error

seemingly at random. Some research has shown this as likely to be a driver

problem and Verifier to be the method to check this. Unfortunately, while

Verifier does throw a different error, stating that a driver is attempting to

corrupt the list, it does not identify the offending driver. Furthermore, I

don't seem to be able to find a dump produced anywhere even though the system

is set to produce a kernal memory dump as well as a log entry.

 

Is there another method to identify the offending driver that I am

overlooking? Does anyone know where the dumps are or why I'm not seeing them?

 

Thanks,

-TC

[Guest Jane C]

Re: PFN_LIST_CORRUPT

 

Hi,

 

The Memory dump should be in C:\Windows

 

http://support.microsoft.com/kb/291806

 

http://msdn2.microsoft.com/en-us/library/ms793247.aspx

 

Have you tested your RAM?

--

Jane, not plain ;) 64 bit enabled :-)

Batteries not included. Braincell on vacation ;-)

MVP Windows Shell/User

 

"TC" <TC@discussions.microsoft.com> wrote in message

news:FB71E966-859A-46D8-B341-CA684604F1B5@microsoft.com...

>I have an x64 Vista Ultimate installation that is getting this error

> seemingly at random. Some research has shown this as likely to be a

> driver

> problem and Verifier to be the method to check this. Unfortunately, while

> Verifier does throw a different error, stating that a driver is attempting

> to

> corrupt the list, it does not identify the offending driver. Furthermore,

> I

> don't seem to be able to find a dump produced anywhere even though the

> system

> is set to produce a kernal memory dump as well as a log entry.

>

> Is there another method to identify the offending driver that I am

> overlooking? Does anyone know where the dumps are or why I'm not seeing

> them?

>

> Thanks,

> -TC

[Guest TC]

Re: PFN_LIST_CORRUPT

 

Jane,

 

Thanks,

Yes, the memory has passed all the checks I have thrown at it. I think I

may have identified at least part of the problem. I recently have been told

that dumps (or minidumps as the case may be) won't be generated unless a page

file of at least 2M exists on the boot volume. I was unaware of this and I

have always moved the page file to a volume other than the boot volume. I

was under the impression that this would help performance. I'm hoping that

by creating a page file on that volume that a dump will be produced and I

will be able to examine the stack trace.

 

-TC

 

"Jane C" wrote:

> Hi,

>

> The Memory dump should be in C:\Windows

>

> http://support.microsoft.com/kb/291806

>

> http://msdn2.microsoft.com/en-us/library/ms793247.aspx

>

> Have you tested your RAM?

> --

> Jane, not plain ;) 64 bit enabled :-)

> Batteries not included. Braincell on vacation ;-)

> MVP Windows Shell/User

>

> "TC" <TC@discussions.microsoft.com> wrote in message

> news:FB71E966-859A-46D8-B341-CA684604F1B5@microsoft.com...

> >I have an x64 Vista Ultimate installation that is getting this error

> > seemingly at random. Some research has shown this as likely to be a

> > driver

> > problem and Verifier to be the method to check this. Unfortunately, while

> > Verifier does throw a different error, stating that a driver is attempting

> > to

> > corrupt the list, it does not identify the offending driver. Furthermore,

> > I

> > don't seem to be able to find a dump produced anywhere even though the

> > system

> > is set to produce a kernal memory dump as well as a log entry.

> >

> > Is there another method to identify the offending driver that I am

> > overlooking? Does anyone know where the dumps are or why I'm not seeing

> > them?

> >

> > Thanks,

> > -TC

>

[Guest Charlie Russel - MVP]

Re: PFN_LIST_CORRUPT

 

yes, you must have a sufficient page file on the boot volume. When you move

it off, it should actually warn you about this side effect. (And yes, there

can be viable performance reasons to move your page file. Though I honestly

don't think the performance improvement is sufficient to be appreciable, and

not enough to make it worth the other problems.)

 

--

Charlie.

http://msmvps.com/xperts64

http://mvp.support.microsoft.com/profile/charlie.russel

 

 

"TC" <TC@discussions.microsoft.com> wrote in message

news:3AA8902F-1EC6-4F95-A658-16D7CF950D9B@microsoft.com...

> Jane,

>

> Thanks,

> Yes, the memory has passed all the checks I have thrown at it. I think I

> may have identified at least part of the problem. I recently have been

> told

> that dumps (or minidumps as the case may be) won't be generated unless a

> page

> file of at least 2M exists on the boot volume. I was unaware of this and

> I

> have always moved the page file to a volume other than the boot volume. I

> was under the impression that this would help performance. I'm hoping

> that

> by creating a page file on that volume that a dump will be produced and I

> will be able to examine the stack trace.

>

> -TC

>

> "Jane C" wrote:

>

>> Hi,

>>

>> The Memory dump should be in C:\Windows

>>

>> http://support.microsoft.com/kb/291806

>>

>> http://msdn2.microsoft.com/en-us/library/ms793247.aspx

>>

>> Have you tested your RAM?

>> --

>> Jane, not plain ;) 64 bit enabled :-)

>> Batteries not included. Braincell on vacation ;-)

>> MVP Windows Shell/User

>>

>> "TC" <TC@discussions.microsoft.com> wrote in message

>> news:FB71E966-859A-46D8-B341-CA684604F1B5@microsoft.com...

>> >I have an x64 Vista Ultimate installation that is getting this error

>> > seemingly at random. Some research has shown this as likely to be a

>> > driver

>> > problem and Verifier to be the method to check this. Unfortunately,

>> > while

>> > Verifier does throw a different error, stating that a driver is

>> > attempting

>> > to

>> > corrupt the list, it does not identify the offending driver.

>> > Furthermore,

>> > I

>> > don't seem to be able to find a dump produced anywhere even though the

>> > system

>> > is set to produce a kernal memory dump as well as a log entry.

>> >

>> > Is there another method to identify the offending driver that I am

>> > overlooking? Does anyone know where the dumps are or why I'm not

>> > seeing

>> > them?

>> >

>> > Thanks,

>> > -TC

>>

[Guest TC]

Re: PFN_LIST_CORRUPT

 

Thanks Charlie,

I'm incredulous. After creating the page file on the boot volume the system

has again crashed with the same error. This time the BSOD looked different.

It actually stated at the bottom that a dump had been prepared and created.

Still I cannot find any newly created .DMP file. I can't find any .DMP

files on the C: drive. I guess I have forgotten what %SystemRoot%\MEMORY.DMP

means. There is no such file in that location. I have changed the system to

produce a minidump in hopes that I will be able to find this file.

 

-TC

 

 

 

"Charlie Russel - MVP" wrote:

> yes, you must have a sufficient page file on the boot volume. When you move

> it off, it should actually warn you about this side effect. (And yes, there

> can be viable performance reasons to move your page file. Though I honestly

> don't think the performance improvement is sufficient to be appreciable, and

> not enough to make it worth the other problems.)

>

> --

> Charlie.

> http://msmvps.com/xperts64

> http://mvp.support.microsoft.com/profile/charlie.russel

[Guest Jane C]

Re: PFN_LIST_CORRUPT

 

Hi TC,

 

Have you got 'show hidden files and folders' checked? IIRC, the dump file

is normally hidden. It should be in C:\Windows

 

--

Jane, not plain ;) 64 bit enabled :-)

Batteries not included. Braincell on vacation ;-)

MVP Windows Shell/User

 

"TC" <TC@discussions.microsoft.com> wrote in message

news:5EE023F5-FDA4-4378-8571-C20FD733C5FD@microsoft.com...

> Thanks Charlie,

> I'm incredulous. After creating the page file on the boot volume the

> system

> has again crashed with the same error. This time the BSOD looked

> different.

> It actually stated at the bottom that a dump had been prepared and

> created.

> Still I cannot find any newly created .DMP file. I can't find any .DMP

> files on the C: drive. I guess I have forgotten what

> %SystemRoot%\MEMORY.DMP

> means. There is no such file in that location. I have changed the system

> to

> produce a minidump in hopes that I will be able to find this file.

>

> -TC

>

>

>

> "Charlie Russel - MVP" wrote:

>

>> yes, you must have a sufficient page file on the boot volume. When you

>> move

>> it off, it should actually warn you about this side effect. (And yes,

>> there

>> can be viable performance reasons to move your page file. Though I

>> honestly

>> don't think the performance improvement is sufficient to be appreciable,

>> and

>> not enough to make it worth the other problems.)

>>

>> --

>> Charlie.

>> http://msmvps.com/xperts64

>> http://mvp.support.microsoft.com/profile/charlie.russel

>

[Guest TC]

Re: PFN_LIST_CORRUPT

 

Yes,

 

Hidden files are set to show.

I found a message in the log that stating that the the dump file could not

be configured. I'm thinking that the page file was not large enough to dump

the entire 4Gb of memory as it was only 2Gb. I have increased the file and

changed the system settings to produce a minidump.

 

I subsequently have turned Verifier back on and, finally, it produced a

minidump, 2 actually, that pointed to bc_ngn.sys as the offending driver.

This is part of the Jetico Personal Firewall. I have un-installed that

software and all of it's drivers. While I'm pretty convinced that this will

solve the problem, I will wait a while before I think the problem is over.

I'm also aware that this PFN list error can also be caused by bad memory, but

I'm hoping the fact that both of the Verifier dumps indicated the same driver

increases the reliability of that information.

 

I have learned a lot about dumps and winDBG that have been valuable lessons.

 

Thanks to you and Charlie for all of your help.

 

-TC

 

"Jane C" wrote:

> Hi TC,

>

> Have you got 'show hidden files and folders' checked? IIRC, the dump file

> is normally hidden. It should be in C:\Windows

>

> --

> Jane, not plain ;) 64 bit enabled :-)

> Batteries not included. Braincell on vacation ;-)

> MVP Windows Shell/User