Какие возможности существуют для анализа после смерти в.NET (например, после сбоя программы)?
Давайте предположим, что есть программа на C#, которая используется в качестве службы Windows. Давайте предположим, что сервис вышел из строя и потребляет процессор и память как сумасшедший. Его нужно перезапустить очень скоро, потому что это производственная система. Так что у меня не так много времени, чтобы собрать информацию во время выполнения. Может быть, быстрый взгляд на диспетчер задач... и все.
После этого у меня есть только файлы журнала log4net и журнал событий Windows для последующего анализа.
Предположим, что я выяснил причину проблемы. Кто-то еще это исправляет, и, возможно, программист добавляет дополнительную запись в журнал, чтобы в следующий раз я мог быстрее найти подобную проблему. Тем не менее: я все еще зависит от качества файлов журнала и надеюсь, что в следующий раз проблема будет как-то проявляться в журналах.
Есть ли и другие способы сделать посмертный анализ? Может быть, что-то вроде дампов потоков (как в java), дампов памяти или чего-то еще, что может помочь в посмертном анализе? Может быть, поможет какой-нибудь встроенный инструмент.NET Framework?
Я очень заинтересован в реальном опыте проекта и в том, как вы пытаетесь решить этот вопрос обслуживания, который, я думаю, очень актуален для большинства программистов.
5 ответов
Как говорит Марк, WinDbg + SoS позволит вам отладить множество проблем, которые вы не можете решить в Visual Studio. В этом блоге есть несколько отличных учебных пособий.
Что касается проблем с памятью, вы также можете посмотреть счетчики производительности.NET в Perfmon. Вы можете посмотреть, где находятся объекты (какое поколение) и сколько времени уходит на сборку мусора. Это должно дать вам некоторую полезную информацию. Если вы хотите знать, почему объект не собирается, WinDbg и SoS - это то, что вам нужно. Чтобы провести вас через простой сеанс, выполните следующие действия:
Осмотрите кучу, используя
!dumpheap -statИщите большое количество экземпляров. Вы, вероятно, имеете некоторое представление о том, что вы ожидаете найти в куче в любой момент, поэтому, если что-то выходит за рамки обычного, посмотрите на это.Выберите случайный экземпляр и сделайте
!gcrootна адрес инстанции. Это скажет вам, почему объект не собирается.Повторение
Вероятные кандидаты на сохранение материала дольше, чем следовало бы: события, статика и очередь финализаторов и многие другие.
Возможно, вы также захотите взглянуть на мой ответ на этот вопрос, чтобы узнать больше о WinDbg.
Вы можете создавать аварийные дампы с помощью.NET и просматривать их с помощью windbg / sos (и sosassist). Не просто, но это работает. Но довольно хардкор. Поиски на "+windbg +.NET" должны оказаться интересными.
Кроме этого - счетчики ресурсов? лог-файлы? Многие вещи, которые вы можете посмотреть, могут быть включены довольно легко.
К сожалению, мне пришлось сделать довольно много этого - лучший инструмент, с которым я столкнулся, это cordbg, который поставляется вместе с SDK (вам понадобится правильная версия для вашей версии.net). http://msdn.microsoft.com/en-us/library/a6zb7c8d.aspx для подробностей.
Присоедините к запущенному процессу в cordbg (a <[pid]>), присоедините к каждому запущенному потоку (t <[tid]>), затем выгрузите стек для каждого потока (w).
Автоматизация этой задачи с помощью небольшого vb-скрипта, а затем выгрузка в файл, позволит вам запустить этот инструмент несколько раз, сохраняя вывод в файл. Сравнение всех стеков потоков даст вам очень хорошее представление о том, на что ваше приложение тратит свое время.
Хорошая особенность этого подхода, особенно в том, что касается автоматизации дампов, заключается в том, что вы можете очень быстро получить всю информацию и перезапустить процесс в кратчайшие сроки.
Отличным ресурсом для посмертного анализа с помощью WinDbg и SOS является серия записей в блоге Тесс Феррандез на эту тему.
РЕДАКТИРОВАТЬ: ссылка обновлена
Если процесс все еще активен, вы можете запустить Managed Stack Explorer, чтобы получить быстрый снимок того, что он делает. Вы можете запустить это без явной установки.
Кроме этого, полный дамп + windbg + SOS дает вам больше информации, но получить ее не тривиально.