Debugging Stop 0x4E - Bad Share Count

Okay, each time I come across a Stop 0x4E, it always seems to point to memory corruption and the last instruction being the MiBadShareCount line. By the way, I've learned that Mi prefix most likely means Internal Memory Management/Manager.

I'll take into consideration, that you would know that are different fields depending upon the PFN Data Structure being used by the operating system, and from my understanding, the above example applies to PFNs being used for a page part of a working set for a process.

For those, who do not know what working set is, it is simply the number of virtual pages present in physical memory for one given process. It is important to remember that software uses virtual memory pages, and these are simply translated into physical addresses by the MMU.

On a side note, I'm still trying to find out what page states the numbers reference, so if anyone knows then please post a comment on this post. Anyway, back to the point, we can see with this bugcheck that either a PFN or PTE data structure has become corrupt. The reason being so, is due to a bad share count and this what I would like to briefly discuss in this blog post.

The Share Count is the number of PTE's which refer to that page (which the PFN Data Structure represents); for page table pages it is the number of valid or transition PTE's in the page table. If the Share Count is above 0, then it is considered not eligible to be removed from memory or the working set for that matter. 

We could view the PFN with the !pfn extension, although, this unfortunately wasn't a viable option for this dump file, and therefore I'm guessing judging by the call stack, that the share count dropped below 0 and the page was removed from memory. We can see this clearly, with the DeleteAddressesInWorkingSet and CleanProcessAddressSpace, both of which are part of the Memory Manager API. The Data Structure probably wasn't updated or became corrupt, so it couldn't be updated to accommodate this change.