flynn017

This is a very simple error, and be can useful in providing a hint at which point the crash may have occurred. This has been explained by Scott Noone on this blog, but I wanted to write my own blog post about it and provide the data structure which he didn't mention. The error was found by Patrick in a Stop 0x101 bugcheck, and perfectly matches the context of the crash. Looking at Parameter 4, we can see the Processor Index Number which has become hung. This is where the error message is located too.  The highlighted address is the physical address stored within the CR3 Register.  Using the !process extension on the same Processor Number Index, we can check the DirBase field to find the mismatch within the two address indicated in the error message. The DirBase is a physical address of the Process Directory Table Base. The DirBase field is the field within structure formatted with !process , which contains the address of the Process Directory Table Base for the current proc...

Okay, I know I've previously explained a Stop 0x101 beforehand, before like a Stop 0x124, I'm going to provide a updated version. Remember you'll need a Kernel Memory dump in order to carry this out. The third parameter contains the PRCB address of the hung processor, the fourth parameter is in fact Reserved, but does contain the processor number of our hung processor. Microsoft like to make us work a little harder. Using the !prcb extension with the processor number, you'll notice that the PRCB address matches the address of the hung processor.  We can also tell that Processor 0 sent out the Clock Interrupt, since the IRQL Level is set to 13. This applies to x64 systems. On a x86 system, the IRQL Level is 28. Clock Interrupts are also hardware interrupts. We can dump the IDT ( !idt ), and then see which interrupt vector clock interrupts and IPIs are assigned to. Okay, we know that Processor 0 sent out the Clock Interrupt, so let's dump the call stack with the knL ...