"PFN_LIST_CORRUPT" BSOD on new build

Original post edited.

Code:

BugCheck 4E, {99, 32531f, 5, 0}

Probably caused by : memory_corruption ( nt!MiBadShareCount+4c )

Code:

6: kd> !stack
Call Stack : 11 frames
## Stack-Pointer    Return-Address   Call-Site       
00 fffff8800ae11938 fffff80002f20a0c nt!KeBugCheckEx+0 
01 fffff8800ae11940 fffff80002e3dea2 nt!MiBadShareCount+4c 
02 fffff8800ae11980 fffff80002e61773 nt!MiDeletePfnList-250ce (perf)
03 fffff8800ae11a10 fffff80002e62842 nt!MiDeleteAddressesInWorkingSet+307 
04 fffff8800ae122c0 fffff80003167a2a nt!MmCleanProcessAddressSpace+96 
05 fffff8800ae12310 fffff8000314db3d nt!PspExitThread+56a 
06 fffff8800ae12410 fffff80002e846da nt!PsExitSpecialApc+1d 
07 fffff8800ae12440 fffff80002e84a20 nt!KiDeliverApc+2ca 
08 fffff8800ae124c0 fffff80002e90eb7 nt!KiInitiateUserApc+70 
09 fffff8800ae12600 00000000772211d6 nt!KiSystemServiceExit+9c

The system seemed to have crashed, as a result of a Bad Share Count, the Share Count is the number of PTE's which correspond to that physical page within the PFN database. This dump file may be difficult to analyse fully, since the !pfn extension can't be used, since the information used by this extension was most likely paged out or not retained at the time of the crash.

The last few frames of the stack seem to be the most relevant, a process was probably closed, and the process object associated with it was deleted since the reference count dropped to 0. The object's pool was probably freed, and the working set pages were also freed. I'm guessing a problem occurred between the PTE's being cleared up properly, and the PFN database.

Run Driver Verifier to scan for any corrupted drivers which may be causing problems, this program works by running various stress tests on drivers, in order to produce a BSOD which will locate the driver; run for least 24 hours:

• Driver Verifier - Enable and Disable

   Information

Additional Help - Using Driver Verifier to identify issues with Drivers

If your interested, or any other debuggers are interested, the MmCleanProcessAddressSpace most likely works the same way in Windows as it does with ReactOS, since ReactOS was built upon the NT specification.

Development | www.reactos.org

Thanks. Just had another crash while I was eating dinner so I didn't see the bsod code. Here is the dmp file it produced. I'll going to run driver verifier after this.

Code:

BugCheck 1000007E, {ffffffffc0000005, fffff80002ecca1f, fffff880033d26b8, fffff880033d1f10}

*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : ntkrnlmp.exe ( nt!KiSwapContext+f )

Code:

fffff880033d26b8 -- (.exr 0xfffff880033d26b8)
ExceptionAddress: fffff80002ecca1f (nt!KiSwapContext+0x000000000000000f)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000000
Attempt to read from address 0000000000000000

Code:

2: kd> k
 # Child-SP          RetAddr           Call Site
00 fffff880`033d28f8 fffff800`02ebf5d2 nt!KiSwapContext+0xf
01 fffff880`033d2a38 fffff800`02ed099f nt!KiCommitThreadWait+0x1d2
02 fffff880`033d2ac8 fffff800`02fa8bd9 nt!KeWaitForSingleObject+0x19f
03 fffff880`033d2b68 fffff880`03179040 nt!ExUnregisterCallback+0x139
04 fffff880`033d2bd8 00000000`00000000 0xfffff880`03179040

Code:

2: kd> !irql
Debugger saved IRQL for processor 0x2 -- 2 (DISPATCH_LEVEL)

The system seemed to have crashed, as a result of a illegal context switch, the IRQL Level was too high for context switches to be used.

The system seemed to have crashed, as a result of a illegal context switch, the IRQL Level was too high for context switches to be used.

What does this mean?

So I ran verifier.exe and it caused all kinds of havoc. I got a LOT of crashes, was unable to boot into windows about a dozen times, and when I could, it usually caused the whole screen to turn into a blurred mass of colors and freeze the computer (video card error?). Once it froze in BIOS. I've attached a newer SF log again. Some of the BSOD codes I got were "IRQL_NOT_LESS_OR_EQUAL" and "Attempt was made to write to read-only memory". These happened on boot and prevented me getting into windows. I managed to boot into safe mode somehow, which is where I'm at now. I disabled the settings on driver verifier, but I don't think that fixed anything.

Code:

BugCheck BE, {fffff900003bad24, 80000003fea00021, fffff8800b223050, b}

Probably caused by : win32k.sys ( win32k!AllocateObject+dd )

The only problem with using Minidumps, is most of the extensions and commands do not give the desired information, since either the stack trace was right at the end of the crash, or the information was paged out. The !pte would have be another useful extension.

Code:

5: kd> k
Child-SP          RetAddr           Call Site
fffff880`0b222ee8 fffff800`02ef77b6 nt!KeBugCheckEx
fffff880`0b222ef0 fffff800`02e77cae nt! ?? ::FNODOBFM::`string'+0x44cde
fffff880`0b223050 fffff800`02e7bde0 nt!KiPageFault+0x16e
fffff880`0b2231e8 fffff800`02e9940c nt!memset+0x50
fffff880`0b2231f0 fffff800`02e9baf1 nt!RtlSetBits+0x8c
fffff880`0b223220 fffff800`02faaf86 nt!MiAllocatePagedPoolPages+0x325
fffff880`0b223340 fffff800`02e999b0 nt!MiAllocatePoolPages+0x906
fffff880`0b223480 fffff800`02fae43e nt!ExpAllocateBigPool+0xb0
fffff880`0b223570 fffff960`000e4dfd nt!ExAllocatePoolWithTag+0x82e
fffff880`0b223660 fffff960`000e64b6 win32k!AllocateObject+0xdd
fffff880`0b2236a0 fffff960`000bd1d0 win32k!SURFMEM::bCreateDIB+0x38a
fffff880`0b223790 fffff960`000bcd4a win32k!hsurfCreateCompatibleSurface+0x3bc
fffff880`0b223860 fffff800`02e78e13 win32k!GreCreateCompatibleBitmap+0x26e
fffff880`0b223940 00000000`73e22e09 nt!KiSystemServiceCopyEnd+0x13
00000000`000d9a88 fffff800`02e711d0 0x73e22e09
fffff880`0b223b20 00000000`00000000 nt!KiCallUserMode

Looking at the stack trace, a new graphics related object was created, and then allocated with paged pool. The allocation was most likely using large pool pages (> 4KB). The problem seemed to have happened on this stack frame:

Code:

5: kd> .frame 3
03 fffff880`0b2231e8 fffff800`02e9940c nt!memset+0x50

Code:

.trap 0xfffff8800b223050
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff900003bad24 rbx=0000000000000000 rcx=fffff900003bad24
rdx=ffffffffffffffff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002e7bde0 rsp=fffff8800b2231e8 rbp=fffff80002e04000
 r8=0000000000000000  r9=0000000000000006 r10=fffff8800426cbd0
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
nt!memset+0x50:
fffff800`02e7bde0 488911          mov     qword ptr [rcx],rdx ds:fffff900`003bad24=ffffffffffffffff

The memset function call, fills the specified number of bytes of memory with data, and since this memory region was read-only, the system bugchecked with the current stop code.

Unfortunately, Driver Verifier wasn't able to pinpoint a driver, however, since the functions being called and causing exceptions are related to graphics. I would suggest you update to the latest WHQL driver of your graphics card driver.