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+0x103fffff900`c2766a10 fffff960`00131a88 win32k!BRUSHOBJ_pvAllocRbrush+0x6cfffff900`c2766a18 fffff960`00abb8c0 vdtw30!DrvTw2RealizeBrush+0x520fffff900`c2766a20 fffff960`00ab713d vdtw30!DrvRealizeBrush+0x6dfffff900`c2766a28 fffff960`001329bc win32k!bGetRealizedBrush+0xae4fffff900`c2766a30 fffff960`00131c71 win32k!BRUSHOBJ_pvGetRbrush+0x2dfffff900`c2766a38 fffff960`00ab9b01 vdtw30!Tw2QueueBitBlt+0x581fffff900`c2766a40 fffff960`00ac73b3 vdtw30!DrvTw2BitBlt+0x513fffff900`c2766a48 fffff960`00ab80ed vdtw30!DrvBitBlt+0x10dfffff900`c2766a50 fffff960`0025478b win32k!OffBitBlt+0x127fffff900`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 Site00 fffff880`14940ac8 fffff800`01e2734f nt!KeBugCheckEx01 fffff880`14940ad0 fffff800`01cc48c7 nt!MiCheckSessionPoolAllocations+0x13f02 fffff880`14940b10 fffff800`01dc2ab5 nt!MiDereferenceSessionFinal+0x13703 fffff880`14940bb0 fffff800`01a56b10 nt!MiDereferenceSession+0x85f7504 fffff880`14940be0 fffff800`01d5ab1a nt!MmCleanProcessAddressSpace+0x61005 fffff880`14940c30 fffff800`01d5aeed nt!PspExitThread+0x56a06 fffff880`14940d30 fffff800`01a765e6 nt!PspTerminateThreadByPointer+0x4d07 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!