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.

Stack:

 # 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!

Comments
  • 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