Ошибка утечки приложения .NET, как найти источник?

Question

У меня есть приложение .NET, работающее в производственной среде (WINDOWS XP + .NET 3.5 SP1) со стабильным значением дескриптора около 2000, но в некоторой неизвестной ситуации количество его обработчиков будет очень быстрым и, наконец, сбой (более 10 000, что контролируется инструментом PerfMon).

Я сделал дамп памяти оттуда во время увеличения периода (пока не врезаться) и импортирован в WinDbg, можно увидеть общее резюме ручки:

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 


   

поэтому не сюрприз, типа утечки является Section, вырыть больше:

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 

может видеть соглашение BaseNamedObjects' именования является всеми MSCTF.MarshalInterface.FileMap.IBC.***.*****.

В принципе, меня остановили здесь, и я не мог пойти дальше, чтобы связать эту информацию с моим приложением.

Любой может помочь?

[Edit0]

Пробовал несколько сочетания GFlags команды (+ust или через пользовательский интерфейс), не повез, отвалы открыты с WinDbg всегда ничего не видят через !htrace, поэтому придется используя процесс прикрепления который в конце концов я получил стек для выше вытекающей ручки:

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

, а затем я застрял снова, стек, похоже, не содержат какой-либо из нашего пользовательского кода, что предложение для продвижения вперед?

Answer 1

WinDbg не является идеальным инструментом для утечек памяти, особенно без предварительной подготовки.

Имеется опция GFlags (+ust), которая может быть включена для процесса записи трассировки стека для распределения дескрипторов. Если у вас нет этого флага, вы, вероятно, не получите больше информации из своего дампа. Если у вас есть это, используйте !htrace, чтобы увидеть стек.

Вы также можете попробовать UMDH (user mode dump heap), что является бесплатным инструментом. Или получите что-то вроде memory validator, который, безусловно, имеет лучшую удобство использования, поэтому он может окупиться в долгосрочной перспективе.