Debugging Stop 0xAB

Note: Before reading this article, please take into consideration this is a old dump file, and the cause of the crash was due to a bug in Windows 8, which Microsoft have now released a fix for, which can be downloaded here - http://support.microsoft.com/kb/2778344

We can see this dump file originates from a Windows 8 system, by using the vertarget command we can gain some useful operating system information.

Another side note, I would like to add with this bugcheck, is make sure you also update your graphics card drivers and the list of installed of Windows Updates/Hot Fixes can be found within the SystemInfo.txt file.

I would like to explain briefly, what Session Space is, and how it related to this bugcheck.

This address space is area of memory assigned to one particular session, and is shared by all the processes within that particular session space. A session is simply all the processes running within that user's logon. Each session is given a Session ID which helps identify each session. More Information - http://blogs.technet.com/b/askperf/archive/2007/07/24/sessions-desktops-and-windows-stations.aspx

 Any Session ID above 0 is the user logon session. The Session 0 is where all the NT processes and services are started. We can view the Session ID in Task Manager, by selecting the View setting and then Selecting Columns option.

I can now see all the processes running under my logon session and user name.

Going back to our bugcheck, we now understand the purpose of Session ID and what session the pool was leaking in, the fourth parameter shows how many pool allocations were leaking. The pool leak was caused by the win32k.sys not releasing it's pool allocations when logging off.

The !pooltag can be used to tell us who the pool allocation belonged to:

We can that it belonged to win32k.sys (part of the Windows subsystem), and that particular allocation was related to the Graphical Device Interface.