Greetings.
The SV&V folks are running a startup/shutdown test of our application. The
test basically starts the application, stops the application then repeats.
Within an hour, the test system bug checks with PFN_LIST_CORRUPT (4E).
This is very repeatable, and it only happens during the shutdown phase of
the test. Here is some crash dump info:
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: 00000099, A PTE or PFN is corrupt
Arg2: 000203e1, page frame number
Arg3: 00000003, current page state
Arg4: 00000000, 0
Debugging Details:
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x4E
LAST_CONTROL_TRANSFER: from 8044d57f to 8044c8f6
STACK_TEXT:
b515caa8 8044d57f 09456000 c0300094 853f57c8 nt!MiDecrementShareCount+0x48
b515cad0 8044d1f2 c0025158 09456000 00000000 nt!MiDeletePte+0x333
b515cb90 8043f6c9 00000000 094cffff 00000000
nt!MiDeleteVirtualAddresses+0x292
b515cc50 804e4095 804e3b42 00000000 800654e0
nt!MmCleanProcessAddressSpace+0x36d
b515cd00 804e3b5c 00000000 851eda88 8042f430 nt!PspExitThread+0x4b7
b515cd0c 8042f430 851eda88 b515cd48 b515cd3c nt!PsExitSpecialApc+0x1a
b515cd4c 80065358 00000001 00000000 b515cd64 nt!KiDeliverApc+0x174
b515cd4c 0d9897a5 00000001 00000000 b515cd64 hal!HalpApcInterrupt+0xb0
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f768 00000000 00000000 00000000 00000000 0xd9897a5
Doing a !process displays info about a process which is not in the active
process list produced by !process 0 0. In fact, the only thread in the
process is the one shown above.
My current working theory is that the monitor process of our application
must have thought the above process was dead and executed a
TerminateProcess() API call, which according to the SDK can result in the
process object (EPROCESS) being left around, but the above process was not
dead and tried to terminate itself. I would have thought the OS would have
some mechanisms to prevent this from happening.
Anyone have any ideas?
Many thanks in advance,
Dale
Just yesterday I posted message titled ‘Bugcheck in MmUnmapViewOfSection’. I
had the same bugcheck and with the same functions on top of the stack. Seems
like in your situation process cleanup code tries to unmap all mapped
addresses or something like that. I fixed the problem by properly
initializing BaseAddress argument in MmMapViewOfSection call. See if that
helps.
----- Original Message -----
From: “Dale Chermak”
To: “NT Developers Interest List”
Sent: Wednesday, November 13, 2002 12:24 AM
Subject: [ntdev] PFN_LIST_CORRUPT Bugcheck
> Greetings.
>
> The SV&V folks are running a startup/shutdown test of our application. The
> test basically starts the application, stops the application then repeats.
> Within an hour, the test system bug checks with PFN_LIST_CORRUPT (4E).
> This is very repeatable, and it only happens during the shutdown phase of
> the test. Here is some crash dump info:
>
> 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: 00000099, A PTE or PFN is corrupt
> Arg2: 000203e1, page frame number
> Arg3: 00000003, current page state
> Arg4: 00000000, 0
>
> Debugging Details:
> ------------------
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x4E
>
> LAST_CONTROL_TRANSFER: from 8044d57f to 8044c8f6
>
> STACK_TEXT:
> b515caa8 8044d57f 09456000 c0300094 853f57c8 nt!MiDecrementShareCount+0x48
> b515cad0 8044d1f2 c0025158 09456000 00000000 nt!MiDeletePte+0x333
> b515cb90 8043f6c9 00000000 094cffff 00000000
> nt!MiDeleteVirtualAddresses+0x292
> b515cc50 804e4095 804e3b42 00000000 800654e0
> nt!MmCleanProcessAddressSpace+0x36d
> b515cd00 804e3b5c 00000000 851eda88 8042f430 nt!PspExitThread+0x4b7
> b515cd0c 8042f430 851eda88 b515cd48 b515cd3c nt!PsExitSpecialApc+0x1a
> b515cd4c 80065358 00000001 00000000 b515cd64 nt!KiDeliverApc+0x174
> b515cd4c 0d9897a5 00000001 00000000 b515cd64 hal!HalpApcInterrupt+0xb0
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0012f768 00000000 00000000 00000000 00000000 0xd9897a5
>
> Doing a !process displays info about a process which is not in the active
> process list produced by !process 0 0. In fact, the only thread in the
> process is the one shown above.
>
> My current working theory is that the monitor process of our application
> must have thought the above process was dead and executed a
> TerminateProcess() API call, which according to the SDK can result in the
> process object (EPROCESS) being left around, but the above process was not
> dead and tried to terminate itself. I would have thought the OS would have
> some mechanisms to prevent this from happening.
>
> Anyone have any ideas?
>
> Many thanks in advance,
>
> Dale
>
> —
> You are currently subscribed to ntdev as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>
Thanks for the tip, but, alas, it did not solve my problem. The
application is actually running on what we call a ‘simulator’, which means
that none of our custom hardware is present, so none of our custom drivers
are installed.
More info: The application uses DirectX 8.1 and when the calls to DX8 are
stubbed out, the BSOD does not occur. We have installed the debug version
of DX8 hoping that something will show up.
How in the world does process show up as not active when a thread of the
process is currently executing on one of the CPUs? It seems like someone
(DX8 maybe?) held onto a process handle of a process that was terminated
but still had an EPROCESS hanging around.
Dale