.NET application handle leak, how to locate the source?

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 MSCTF.MarshalInterface.FileMap.IBC.***.*****.

Basically I was stopped here, and could not go any further to link the information to my application.

Anyone could help?

[Edit0]

Tried several combination of GFlags command(+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.

You can also try UMDH (user mode dump heap), which is a free tool. Or get something like memory validator which has certainly a better usability, so it might pay off in the long run.