Another simple memory management case to debug, I thought I explained working set beforehand, but it seems that isn’t true so I’ll also be explaining working set and the Working Set Manager.
The first parameter indicates the subtype of the bugcheck, in this case the 5003 corresponds to a corrupt working set free list which is usually a result of a hardware problem. The second parameter (undocumented) contains the address of the working set list for a given process.
Before, we go directly explaining the bugcheck, let’s take a look at working set.
Working Set is simply a group of virtual pages allocated to a process which are present within physical memory (RAM). Windows by default sets the working set limits to a minimum of 50 pages and a maximum of 345 pages. However, these limits have little effect, since a process can exceed the maximum page limit as long as there is enough physical memory. The minimum and maximum working set can be set by the user with the SetProcessWorkingSetSize function. However, this isn’t recommended by Microsoft and other developers, a few good threads can be found here and here.
The !process extension can give us the working set for a given process.
The data structure applies to each individual page within a working set for a process.
It contains one field named Age, which is counter for when the Working Set Manager has incremented it’s age value, because it hasn’t been accessed. The counter’s maximum is 7, and this is when a page is removed from the working set. The Working Set Manager is called by a system thread called the Balance Set Manager which waits upon two event objects. A event which is signaled upon a timer object is set to the signaled state every second, and a working set manager event which is signaled in certain memory conditions.
Code Machine – _MMWSLE