Можно ли запустить сборку мусора .NET из WinDbg?

Question

Я выясняю, почему управляемый процесс использует много памяти. Есть ли способ запустить GC.Collect(3) из WinDbg, чтобы я мог сосредоточиться на фактическом распределении памяти?

Answer 1

Я не думаю, что есть какой-либо способ запустить сборку мусора .NET из WinDbg, но я также не думаю, что это необходимо.

См. Замечания Рико Мариани о производительности - отслеживание управляемых утечек памяти (как найти утечку ГХ) для получения информации о том, какие вещи находятся в вашей куче.

Дополнительные, возможно, полезные ссылки:

• Когда вызывать GC.Collect ()
• Скотт Дорман - Управление памятью .NET - Ресурсы

Answer 2

Я не верю, что вы можете запустить GC из WinDbg.

Вот некоторые полезные инструменты, которые я использовал для отслеживания выделения памяти:

• SOSEX - дальнейшее продление для WinDbg, чтобы дополнить SOS, который добавляет! dumpgen для сброса объектов из конкретное поколение (отлично подходит для выяснить, что на LOH и в Gen 2) и команда! refs который даст родительские ссылки для объект.
• . Net Memory Profiler - это очень полезный инструмент при запуске в интерактивном режиме, но также содержит возможность загрузки из файла дампа. Это дает достаточно интуитивный способ отслеживать использование памяти. Легко стоит 250 долларов США, но у них также есть 14-дневный eval.

Answer 3

WinDBG - это прежде всего Win32 / Kernel Debugger. Поэтому вы можете попробовать один из управляемых отладчиков, например mDBG . Но я использовал поддержку отладки .NET для MSFT, и мне никогда не требовалось ничего подобного для устранения утечек памяти.

Answer 4

Привет, Роджер, надеюсь, утечка памяти уже устранена. : -)

Сначала я был бы уверен, что это «управляемая утечка памяти». Я имею в виду, что когда вы смотрите на счетчики системного монитора .NET CLR Memory -> # байт во всех кучах увеличивается с той же скоростью, что и счетчик Process -> Private Bytes для тот же процесс. Если это так, то вы можете использовать методы, описанные выше.

Если это не так, у вас может быть собственная утечка, которая является результатом запуска управляемого кода. Чаще всего я вижу, что сборки .NET загружаются в процессе, а не выгружаются. Это похоже на утечку памяти в Perfmon.

Я бы посоветовал вам попробовать запустить правило утечки в DebugDiag и посмотреть, что в отчете памяти отображается как утечка стеков вызовов.

Вот еще один замечательный ресурс на эту тему: У меня утечка памяти !!! Что я делаю? (определяя "где")

Спасибо, Аарон