I have a .NET application running in production environment (WINDOWS XP + .NET 3.5 SP1) with a stable handle count around 2000, but in some unknown situation, its handle count will increase extremely fast and finally crash itself(over 10,000 which monitored by PerfMon tool).
I've made a memory dump from there during the increasing period (not crash yet) and imported to WinDbg, can see the overall handle summary:
0:000> !handle 0 0 7229 Handles Type Count None 19 Event 504 Section 6108 File 262 Port 15 Directory 3 Mutant 56 WindowStation 2 Semaphore 70 Key 97 Token 2 Process 3 Thread 75 Desktop 1 IoCompletion 9 Timer 2 KeyedEvent 1
so no surprise, the leak type is the
Section, dig more:
0:000> !handle 0 ff Section Handle 00007114 Type Section Attributes 0 GrantedAccess 0xf0007: Delete,ReadControl,WriteDac,WriteOwner Query,MapWrite,MapRead HandleCount 2 PointerCount 4 Name \BaseNamedObjects\MSCTF.MarshalInterface.FileMap.IBC.AKCHAC.CGOOBGKD No object specific information available Handle 00007134 Type Section Attributes 0 GrantedAccess 0xf0007: Delete,ReadControl,WriteDac,WriteOwner Query,MapWrite,MapRead HandleCount 2 PointerCount 4 Name \BaseNamedObjects\MSCTF.MarshalInterface.FileMap.IBC.GKCHAC.KCLBDGKD No object specific information available ... ... ... ... 6108 handles of type Section
can see the
BaseNamedObjects' naming convention are all
Basically I was stopped here, and could not go any further to link the information to my application.
Anyone could help?
Tried several combination of
+ust or via UI), with no luck, the dumps opened with WinDbg always see nothing via
!htrace, so have to using attach process which finally I got the stack for above leaking handle:
0:033> !htrace 1758 -------------------------------------- Handle = 0x00001758 - OPEN Thread ID = 0x00000768, Process ID = 0x00001784 0x7c809543: KERNEL32!CreateFileMappingA+0x0000006e 0x74723917: MSCTF!CCicFileMappingStatic::Create+0x00000022 0x7473fc0f: MSCTF!CicCoMarshalInterface+0x000000f8 0x747408e9: MSCTF!CStub::stub_OutParam+0x00000110 0x74742b05: MSCTF!CStubIUnknown::stub_QueryInterface+0x0000009e 0x74743e75: MSCTF!CStubITfLangBarItem::Invoke+0x00000014 0x7473fdb9: MSCTF!HandleSendReceiveMsg+0x00000171 0x7474037f: MSCTF!CicMarshalWndProc+0x00000161 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\USER32.dll - 0x7e418734: USER32!GetDC+0x0000006d 0x7e418816: USER32!GetDC+0x0000014f 0x7e4189cd: USER32!GetWindowLongW+0x00000127 --------------------------------------
and then I got stuck again, the stack seems not contain any of our user code, what is the suggestion for move forward?
WinDbg isn't the ideal tool for memory leaks, especially not without preparation in advance.
There's a GFlags option (
+ust) which can be enabled for a process to record the stack trace for handle allocations. If you don't have this flag enabled, you'll probably not get more info out of your dump. If you have it, use
!htrace to see the stack.
User contributions licensed under CC BY-SA 3.0