Debugging In Progress...

This blog is intended to provide information on debug issues encountered in Microsoft Support, such as STOP errors or hanging servers.

[RESOLVED] Win2008R2 SP1: STOP 0xAB with tag Gdbr (nt!MiCheckSessionPoolAllocations+0x13f)

[RESOLVED] Win2008R2 SP1: STOP 0xAB with tag Gdbr (nt!MiCheckSessionPoolAllocations+0x13f)

  • Comments 3
  • Likes

Status: Resolved

Update 121122: Finally! After many rounds of instrumentation we nailed this nasty bug as well! :D It's now resolved in KB2786447, to be released in January 2013 (REL13-01).

Update 120417: We currently have a new round of instrumentation running... fingers crossed!

Update 120323: After opening an RFC for this we got new dumps with instrumentation, showing us the following call stack related to the Gdbr allocation that's causing the STOP 0xAB:

fffff900`c2766a08  fffff960`0004b78f win32k!AllocAndTrackPool+0x103
fffff900`c2766a10  fffff960`00131a88 win32k!BRUSHOBJ_pvAllocRbrush+0x6c
fffff900`c2766a18  fffff960`00abb8c0 vdtw30!DrvTw2RealizeBrush+0x520
fffff900`c2766a20  fffff960`00ab713d vdtw30!DrvRealizeBrush+0x6d
fffff900`c2766a28  fffff960`001329bc win32k!bGetRealizedBrush+0xae4
fffff900`c2766a30  fffff960`00131c71 win32k!BRUSHOBJ_pvGetRbrush+0x2d
fffff900`c2766a38  fffff960`00ab9b01 vdtw30!Tw2QueueBitBlt+0x581
fffff900`c2766a40  fffff960`00ac73b3 vdtw30!DrvTw2BitBlt+0x513
fffff900`c2766a48  fffff960`00ab80ed vdtw30!DrvBitBlt+0x10d
fffff900`c2766a50  fffff960`0025478b win32k!OffBitBlt+0x127
fffff900`c2766a58  fffff960`00ad67a9 vdtw30!DrawFrame+0xd69 

On Monday Engineering will continue research on this...


Since a few days I am working on two STOP 0xABs, where the leaking tag is Gdbr, as identified from the !poolused 8 output.


 # Child-SP          RetAddr           Call Site
00 fffff880`14940ac8 fffff800`01e2734f nt!KeBugCheckEx
01 fffff880`14940ad0 fffff800`01cc48c7 nt!MiCheckSessionPoolAllocations+0x13f
02 fffff880`14940b10 fffff800`01dc2ab5 nt!MiDereferenceSessionFinal+0x137
03 fffff880`14940bb0 fffff800`01a56b10 nt!MiDereferenceSession+0x85f75
04 fffff880`14940be0 fffff800`01d5ab1a nt!MmCleanProcessAddressSpace+0x610
05 fffff880`14940c30 fffff800`01d5aeed nt!PspExitThread+0x56a
06 fffff880`14940d30 fffff800`01a765e6 nt!PspTerminateThreadByPointer+0x4d
07 fffff880`14940d80 00000000`00000000 nt!KxStartSystemThread+0x16

12: kd> !poolused 8
 Sorting by Session Tag

               NonPaged                  Paged
 Tag     Allocs         Used     Allocs         Used

 Gdbr         0            0          2          920 Gdi driver brush realization
 Pool         1         4096          0            0 Pool tables, etc.

TOTAL         1         4096          2          920

Both customers are running an instrumented win32k.sys currently, to track down the root cause of the leak. Stay tuned and let me know when your machine hits this too!

  • call stacks with vdtw30 are always good to keep an eye on. :)

    I will see if any of my customers experience this issue ....

  • Thanks, keep me posted Christoph! :)

  • I like the work you are doing here!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment