flynn017

Again, this is a updated version of a previous blog post, since I will able to show things in more depth. This is a bugcheck caused by Driver Verifier finding a violation, it indicates that a process or driver has used a User-Mode handle in Kernel-Mode. I've highlighted the two parameters which are the most important in this bugcheck. The value of the handle, and the address of the current process. Since this is a Driver Verifier bugcheck, the driver is most likely going to be displayed, so this post is more about understanding what it references and what it did wrong. By using the !process extension, we can dump some information about the process, and view the number of handles it currently holds. Using the !handle extension with the value of the handle being referenced in parameter 3, gives some information about the object which the handle is currently referencing. It seems to be a registry key. Let's take a closer look into the registry key, just for academic and nerdy in...

Splay Trees are an example of a binary search tree, which is a data structure for arranging and sorting data, which is sorted into nodes. They make good use of pointers. Splay Trees share the same structure as a standard binary search tree, but provide benefits such as the most accessed node always being the root or top of the tree. There three standard algorithms for splaying the node to the root of the tree, and these depend upon the positioning and depth of the node within the Splay Tree. Splay Trees are used in IFS (Installable File Systems). The length of the time taken to complete a algorithm for a Splay Tree, can be calculated with the Big O notation. There's no randomisation within Splay Trees, and therefore some operations can be expensive and time consuming, this is especially true when Splay Trees become unbalanced and very tall. It could take many Zig operations to splay a node to the root of the tree. Each rotation is called a Splay Step, and the process is called Spla...

I've explained how to debug a Stop 0x9F in previous blog posts, but here I'm going to explain how exactly it detects a timeout, and thus bugchecks with the Stop 0x9F. We should understand now, that the two highlighted parameters are the most important for this type of bugcheck. The fourth parameter shows the Blocked IRP which caused the timeout, and the second parameter is the PDO of the device the driver is associated with. Lets look at the blocked IRP, using the !irp extension. So, we can see that a power related IRP is pending, and has held too long by a device object leading to the crash. tunnel.sys seems to be associated with the IRP, however, this isn't the exact problem here. We can see that tunnel.sys calls GsDriverEntry , which is a routine called after the driver is loaded and initialized. It take two parameters: a pointer to the DRIVER_OBJECT data structure, and a pointer to the path in the registry where the driver is stored. It's called at IRQL Level 0. ...

Like before with the Stop 0x101, I'm going to provide a updated version of a Stop 0x4A which will contain some more information. We should all understand what IRQL Levels and the differences between Kernel-Mode and User-Mode. The general nature of this bugcheck indicates that the a thread has returned to User-Mode from Kernel-Mode at a IRQL Level greater than Level 0 or PASSIVE_LEVEL. All User-Mode runs at IRQL Level 0. System Service Calls are interrupts, and are handled by the System Service Dispatcher. We can view the IDT, and see which interrupt vector the System Service Dispatcher is stored at.   You could also use the rdmsr (read Model Specific Register) with the address of 176, to view the sysenter instruction handler which is used on modern processors. The IDT is more backwards compatibility for older processors. The sysenter instruction is executed and enabled transition into Kernel Mode. The sysexit instruction is used to exit Kernel-Mode, and return to User-Mode. I...

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

After this blog post, I think I've covered all the aspects of a Stop 0x124. Otherwise, you may see a few more posts about it in the future. I'm also planning on adding a few more debugging extensions, and will provide a updated version of a Stop 0x101. WHEA General Structure and Reporting: WHEA has the following general component structure:   LLHEHs are used to perform hardware error source discovery, gather information about the error source in the form of Hardware Error Packets, and then notify the operating system of the error. The Windows Kernel then formats these Hardware Error Packets into Error Records. Here is the general format of a Error Record for WHEA:  Each Error Record is described by the WHEA_ERROR_RECORD structure which provides information about the error condition. This is then saved in the Event Log through ETW (Event Tracing for Windows). When a error condition has happened, the LLHEH may communicate with the PSHED to receive platform specific information ...

Another blog post about Stop 0x124, as always said, these bugchecks are probably one of the hardest to debug due to the lack of information they retain, thereby it's very important to understand how to gather as much as possible from these seemingly barren dump files. I'm going to explain the rest of the !sysinfo extensions, !cpuinfo , !whea and !errpkt . In regards to !sysinfo , I'm going to discuss the flags to the extension highlighted with the red box. Let's begin with the !cpuinfo extension, which will show some basic information about the CPU. By default, it will display information about all the processors in the system, however, since this is a Mindump so one processor; the processor which was last running will be shown. The MHz field shows the clockspeed of the processor. The Manufacturer field is used to show that the processor is a real Intel processor. The CP field shows the current processor number. The F indicates the processor family number; the M indic...