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!

About 0x14c

I'm currently a Software Developer. My primary interests are Mathematics, Programming and Windows Internals.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.