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, and thus leads me to believe this is more of a software related issue. To support my point further, using the !thread extension I was able to find a pending IRP for the crashed thread, although, since this is a Minidump and not a Kernel Memory dump, I’m not able to use the !irp extension and view the stack for the IRP.
I’ve requested the use of Driver Verifier for the user. In an idea world, I would have had a Kernel Memory dump and checked the IRP.
Side Note: I hope this article helps anyone, and I do try to update my blog as much as possible, but it may be only a few blog posts a month since I attempt to find good debugging examples and write blog posts with examples to support concepts e.g. Working Set Internals