PFN_LIST_CORRUPT

[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

 

[Jane C]

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

 

[TC]

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
>

 

[Charlie Russel - MVP]

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
>>

 

[TC]

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

 

[Jane C]

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
>

 

[TC]

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