Исследование утечки памяти в приложении.Net с использованием DebugDiag и WinDbg
Я пытаюсь диагностировать утечку памяти в клиентском приложении C#. Это приложение:
- работает в усиленной среде Windows
- взаимодействует с локальным неуправляемым сторонним API
- общается через tcp с приложением сервера
- Воспроизведение файлов WAV через waveOutWrite()
- интегрируется с пользовательской USB-клавиатурой через dll производителя клавиатуры
- принимает пользовательский ввод для выполнения действий против стороннего API
При обычном использовании приложения, в зависимости от конфигурации клиента, используется от 50 до 100 МБ памяти. Наше последнее обновление этого приложения работало без проблем в течение нескольких недель (в течение этого времени не было проблем с памятью). Затем, без каких-либо изменений кода или каких-либо изменений на клиентских компьютерах, о которых знает клиент, мы начали испытывать следующее:
- Неконтролируемый, быстрый и / или постепенный рост памяти до тех пор, пока не будут выброшены исключения из памяти
- Прерывистая задержка / неустойчивый отклик от пользовательской клавиатуры
- waveOutWrite() возвращает значение ошибки 1, когда мы пытаемся воспроизвести звук (происходит до того, как объем памяти приблизится к максимальному использованию)
Я использовал DebugDiag 1.2 для мониторинга утечек и получения полного дампа. Начальные предупреждения от анализа:
Дамп показывает 1,19 ГБ выделения в Native Heaps. 634 МБ из кучи времени выполнения Microsoft VC (частной) и 549 МБ из кучи DebugDiag LeakTrack. Кучи 634 МБ имеет 44 сегмента, большинство из которых - 15,81 МБ.
Тем не менее, отчет о распределении не соответствует. Максимальное выделение по размеру составляет 992 КБ, а также по количеству 3 в начале. Вот основные распределения для кучи 634 МБ:
Я читаю это неправильно?
Переход на WinDbg, если я запустил !heap -stat -h [634MBheapaddress] -grp B, Я получил:
group-by: BLOCKCOUNT max-display: 20
size #blocks total ( %) (percent of totalblocks)
44 9ea51 - 2a23d84 (44.14)
1a 1fba7 - 338ef6 (8.83)
18 1b3b8 - 28d940 (7.58)
10 16913 - 169130 (6.28)
12 1222c - 146718 (5.05)
22 d9d0 - 1ceda0 (3.79)
1c 9bea - 110d98 (2.71)
14 9197 - b5fcc (2.53)
26 9115 - 15891e (2.52)
20 6774 - cee80 (1.80)
24 5094 - b54d0 (1.40)
30 4b03 - e1090 (1.30)
78 4a81 - 22ec78 (1.30)
28 48d2 - b60d0 (1.27)
4 48bb - 122ec (1.26)
58 48aa - 18fa70 (1.26)
1e 48a6 - 88374 (1.26)
2a 48a3 - beabe (1.26)
16 4898 - 63d10 (1.26)
600 4884 - 1b31800 (1.26)
Если я читаю это правильно, он показывает верхнее распределение как 68 байтов и имеет распределение 650 КБ. Это правильно? Если это так, то это может быть потенциальная проблема, но она составляет только 44 МБ - нигде около 650 МБ, которые я показываю как зарезервированные
В любом случае, на данный момент я не уверен, как выяснить, что это за ассигнования или что их делает. И я в растерянности относительно того, почему проблемы начали бы возникать без какого-либо изменения кода с нашей стороны. Я должен предположить, что что-то изменилось в системах клиентов, о которых они не знают и которые выявили ошибку в нашем коде, но до сих пор мне не повезло выяснить причину.
Любая помощь будет принята с благодарностью!