Thursday 28 November 2013

Debugging Stop 0x4A [Updated Version]

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. In some circumstances, like when the Single Step (or Trap) flag has been enabled, the iretd (Interrupt Return) instruction may be used instead.

In this instance, the flag is disabled and not set:


The Trap flag causes the processor to execute one instruction and then stop. This can cause a crash if used with the sysexit instruction.

Check Volume 3 Chapter 35 in the Intel Developer's Manual for more information about MSRs.

The syscall and sysret are used to call and return from System Calls stored within the System Call Descriptor Table. The System Call Number which is used to look in the SSDT and execute the System Call routine is stored within the eax register. The parameters of the call are stored on the Kernel Stack of the thread to prevent modification from User-Mode.

We can view the SSDT here:


On x86 systems, these structure can be hooked onto and patched.

Getting back to the topic of the thread, it appears that the IRQL Level is 2.


I also went and checked the last process, we seems to point to Bitdefender. I've seen Bitdefender directly cause a bugcheck like this before.



Additional Reading:

User-Mode Interactions: Guidelines for Kernel Mode Drivers

Hooking Shadow SSDT on Windows 7

1 comment: