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

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

  • Anonymous
    March 27, 2012
    call stacks with vdtw30 are always good to keep an eye on. :) I will see if any of my customers experience this issue ....

  • Anonymous
    April 05, 2012
    Thanks, keep me posted Christoph! :)

  • Anonymous
    May 26, 2012
    I like the work you are doing here!