Randomly occuring "Memory Management" BSODs?

Ok and thank you for your help

// PelleK63

Thanks Noel :)

PelleK63, have you had any other BSODs yet?

Hello x Bluerobot,

No, the PC has been running with the driver verifier on for close to 18 hours now.

So far, it's been stable. I would be happy but at the same time mystified if I didn't get any more BSODs now.

I would always wonder what the h**l the problem was

That's great to know, let's hope it stays without BSODs

Hello again,

After running stable for nearly a week, I just got a BSOD again. Fortunately, this time I got a new crash dump file. New SF Diag File attached.

Regards // PelleK63

Code:

BugCheck 1A, {41790, fffffa800538e8a0, ffff, 0}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+35084 )

It's the same BSOD we have had recently, the text is green is the page which is corrupted, using !poolval we can see that a allocation was most likely overwritten.

Code:

6: kd> !poolval fffffa800538e8a0
Pool page fffffa800538e8a0 region is Nonpaged pool

Validating Pool headers for pool page: fffffa800538e8a0

Pool page [ fffffa800538e000 ] is __inVALID.

Analyzing linked list...
[ fffffa800538e000 ]: invalid previous size [ 0x80 ] should be [ 0x0 ]
[ fffffa800538e000 --> fffffa800538e220 (size = 0x220 bytes)]: Corrupt region


Scanning for single bit errors...
[ fffffa800538e000 ]: previous size [ 0x80 ] should be [ 0x0 ]

I would run Driver Verifier again for around 36 hours instead, something is corrupting a page of pool within the page table.

Ok, I'll turn driver verifier on again and will leave it on until the next BSOD occurs.

Would be nice to get to the bottom of this :)

I know, at least we have some consistency with the types of BSODs going on here :)

Code:

2: kd> dt nt!_MMPFN fffffa80052e4bf0
   +0x000 u1               : <unnamed-tag>
   +0x008 u2               : <unnamed-tag>
   +0x010 PteAddress       : 0xfffff6fb`41ffbbb8 _MMPTE
   +0x010 VolatilePteAddress : 0xfffff6fb`41ffbbb8 Void
   +0x010 Lock             : 0n1107278776
   +0x010 PteLong          : 0xfffff6fb`41ffbbb8
   +0x018 u3               : <unnamed-tag>
   +0x01c UsedPageTableEntries : 0xffff
   +0x01e VaType           : 0 ''
   +0x01f ViewCount        : 0 ''
   +0x020 OriginalPte      : _MMPTE
   +0x020 AweReferenceCount : 0n128
   +0x028 u4               : <unnamed-tag>

The cause of the bugcheck "1A (41790)" is the PFN UsedPageTableEntries counter going below zero (see here). If Verifier doesn't detect the violator, it might simply not have a test for this kind of bug. It looks like a page table entry being deleted more than once.