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

Question

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

Answer 1

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

Видишь Пикантные моменты производительности Рико Мариани - Отслеживание утечек управляемой памяти (как найти утечку GC) для получения информации о том, как узнать, что за материал находится в вашей куче.

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Сначала я бы убедился, что это "управляемая утечка памяти".Под этим я подразумеваю, что когда вы смотрите на счетчики монитора производительности Память .NET CLR -> # Байт во всех кучах увеличивается с той же скоростью, что и Процесс -> Личные байты счетчик для того же процесса.Если это так, то вы можете использовать методы, описанные выше.

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

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

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

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