Можно ли просмотреть все объекты .net, которые собираются при вызове GC.Collect()?Как отлаживать .net Сбор мусора?
Мне нужно увидеть, какие объекты все еще хранятся в памяти и не возвращены, поэтому я могу найти, где исправление объектов должно было быть сделано вручную, но было забыто программистом.
Я не хочу вызывать GC.Collect, потому что кто-то где-то забыл уничтожить объект, который блокирует некоторые ручки.
Я нашел, что лучший способ сделать это - использовать windbg и SOS (сын забастовки). У него довольно критическая командная строка, но она очень мощная. Он имеет возможность сбросить кучу и разделить ее на кучу генерации GC. Как только вы пройдете начальную кривую обучения, очень легко отслеживать, какие объекты живы в какой части кучи. Вот несколько веб-сайтов с примерами использования SOS
EDIT OP спросил о местонахождении SOS.dll. Он включен в установку .Net Framework. Он расположен в
% WINDIR% \ Microsoft.NET \ Framework \ v2.0.50727 \ SOS.dll
Но как только вы WinDbg загружены не нужен полный путь. Просто мы.
.loadby Сос Mscorwks.dll
Это будет выглядеть для версии СЦ в том же каталоге, что и текущая версия mscorwks (Среда CLR)
я использую SciTech's Memory profiler. Это немного сложно использовать с летучей мыши, но есть хорошие учебные видео. Это позволит вам посмотреть, какие объекты не расположены должным образом, в каком поколении они были собраны. Не удалось отладить утечки памяти без него ...
«должно быть [собрано]» является нечетной фразой с GC – user7116
Я слышал, как люди говорят, что все время! Дев говорит: «Это вне сферы действия, почему он не собран?» с предположением, что GC автоматически выполнит * все *. Хотя это замечательная работа, она не идеальна. Чем больше вы знаете GC, тем больше вы знаете, что можете утечь память, если не будете осторожны. –
«должен иметь ...» не ссылался на GC, а на ручную утилизацию объекта - извините за запутанное использование языка! – Sam