Posts

Showing posts with the label Stop 0x1A

Debugging Stop 0x1A - Corrupt PTE Undocumented Parameters Revealed

A very good post on Sysnative from muhahaa, illustrating the meanings behind the undocumented parameters seen in a Stop 0x1A, as result of a corrupt PTE. Re: Need help with random BSOD's (Packard Bell EasyNote ML61) I'm also planning on explaining all the registers, and their purposes, first part should be published tomorrow at some point.

Debugging Stop 0x1A - Working Set Free List Corrupt

Image
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: 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 ...

Debugging Stop 0x1A - Corrupt Image Relocation Table

Image
This blog is most likely, going to be more of me attempting to explain relocation and the relocation fix up table. The first parameter indicates that image relocation fix-up table has become corrupt, the image relocation table is a table of pointers for a program, which are used to assign memory addresses to parts of the program. Each pointer is called a fix-up. Pointers are basically used in programming, to assign or use memory addresses in programs. The MSDN documentation points out, that this issue is more hardware related, and therefore the only valid reasons I could think of are - corrupt memory addresses are being assigned or maybe the MMU wasn't translating virtual pages to physical pages, resulting in invalid memory addresses.

Debugging Stop 0x1A - Out of Sync PFNs and Page Tables

Image
I've seen this bugcheck and it's parameter 403, becoming more common recently, and therefore thought I would share how I go around debugging the problem. Stop 0x1As rarely tell us what the parameters actually indicate and substitute to, therefore we need to check some documentation provided by Microsoft on their WDK (Windows Driver Kit) on MSDN. Stop 0x1A Documentation - Bug Check 0x1A: MEMORY_MANAGEMENT "The page table and PFNs are out of sync . This is probably a hardware error, especially if parameters 3 & 4 differ by only a single bit." The above is the meaning for the first parameter of 403, remember to always check the first parameter, the other parameters are usually meaningless unless you probably work for Microsoft. So, in this example, we need to examine the binary representation of the two parameters and then compare their bits. We can use the .formats command to examine and compare the two parameters together like so:  The parameters differ greatly...