Debugging Stop 0x4A - User-Mode and IRQL Levels

Okay, here's another debugging example which has quite a simple methodology, a driver has returned to User-Mode while the IRQL Level was above PASSIVE_LEVEL or Level 0.

The first parameter indicates the IRQL Level of the processor, in which in this case is Level 2 or DISPATCH_LEVEL. The first parameter indicates the address of the system call in which the driver has returned from.

The main point to remember is that all threads which run in User-Mode run at the IRQL Level of 0, this is ensure that no User-Mode thread has a higher interrupt priority than any Kernel-Mode threads. In case, you wondering which cases a User-Mode application may need to call into Kernel-Mode, a good listing of examples can be found here - User-Mode Interactions: Guidelines for Kernel-Mode Drivers

The stack does not reveal much, apart from this:

The stack simply reveals a function in User-Mode calling the nt!KiServiceExit2 routine, which is a internal Kernel routine.

The use of dd command in a stack can be found here - [Advanced] Principles of debugging

The driver which seems to be causing the problem is related to the Bitdefender program.

I understand, this was a very short and brief tutorial, but to be honest there isn't much behind this bugcheck apart from what I have already explained.

Happy Halloween!