Какие возможности существуют для анализа после смерти в .NET (например, после сбоя программы)?

Question

Предположим, что есть программа на C #, которая используется в качестве службы Windows. Давайте предположим, что сервис вышел из строя и потребляет процессор и память как сумасшедший. Его нужно перезапустить очень скоро, потому что это производственная система. Так что у меня не так много времени, чтобы собрать информацию во время выполнения. Может быть, быстрый взгляд на диспетчер задач ... и все.

После этого все, что у меня есть, - это файлы журнала log4net и журнал событий Windows для анализа после смерти.

Предположим, я выяснил причину проблемы. Кто-то еще это исправляет, и, возможно, программист добавляет дополнительные записи в журналы, чтобы в следующий раз я мог быстрее найти подобную проблему. Тем не менее: я все еще зависит от качества файлов журнала и надеюсь, что в следующий раз проблема будет как-то проявляться в журналах.

Существуют ли другие способы проведения посмертного анализа? Может быть, что-то вроде дампов потоков (как в java), дампов памяти или чего-то еще, что может помочь в анализе после смерти? Может быть, поможет какой-нибудь встроенный инструмент .NET Framework?

Я очень заинтересован в реальном опыте проекта и в том, как бы вы попытались решить этот вопрос обслуживания, который, я думаю, очень актуален для большинства программистов.

Answer 1

Как говорит Марк, WinDbg + SoS позволит вам отладить множество проблем, которые вы не можете решить в Visual Studio. Есть несколько отличных учебников в этом блоге .

При возникновении проблем с памятью вы также можете посмотреть счетчики производительности .NET в Perfmon. Вы можете посмотреть, где находятся объекты (какое поколение) и сколько времени уходит на сборку мусора. Это должно дать вам некоторую полезную информацию. Если вы хотите знать, почему объект не собирается, WinDbg и SoS - это то, что вам нужно. Чтобы провести вас через простую сессию, выполните следующие шаги:

1. Проверьте кучу, используя !dumpheap -stat, найдите большое количество экземпляров. Вы, вероятно, имеете некоторое представление о том, что вы ожидаете найти в куче в любой момент, поэтому, если что-то выходит за рамки обычного, посмотрите на это.

2. Выберите случайный экземпляр и введите !gcroot адрес экземпляра. Это скажет вам, почему объект не собирается.

3. Повторите

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

Вы также можете взглянуть на мой ответ на этот вопрос , чтобы узнать больше о WinDbg.

Answer 2

Вы можете создавать аварийные дампы с помощью .NET и просматривать их с помощью windbg / sos (и sosassist). Не просто, но это работает. Но довольно хардкор. Поиск по "+ windbg + .NET" должен оказаться интересным.

Кроме этого - счетчики ресурсов? лог-файлы? Многие вещи, которые вы можете посмотреть, могут быть включены довольно легко.

Answer 3

К сожалению, я должен был сделать изрядное количество этого - лучший инструмент, с которым я столкнулся, - это cordbg, который поставляется с sdk (вам понадобится правильная версия для вашей версии .net). http://msdn.microsoft.com/en-us/library/a6zb7c8d.aspx для деталей.

Присоединить к запущенному процессу в cordbg (a <[pid]>), присоединить к каждому запущенному потоку (t <[tid]>), затем выгрузить стек для каждого потока (w).

Автоматизация этой задачи с помощью небольшого vb-скрипта с последующим выводом в файл позволит вам запустить этот инструмент несколько раз, сохраняя вывод в файл. Сравнение всех стеков потоков даст вам очень хорошее представление о том, на что ваше приложение тратит время.

Хорошая особенность этого подхода, особенно в том, что касается автоматизации дампов, заключается в том, что вы можете очень быстро получить всю информацию и перезапустить процесс в кратчайшие сроки.

Answer 4

Отличным ресурсом для посмертного анализа с помощью WinDbg и SOS является серия записей в блоге Тесс Феррандез * на эту тему.

РЕДАКТИРОВАТЬ: ссылка обновлена ​​

Answer 5

Если процесс все еще активен, вы можете запустить Managed Stack Explorer для него, чтобы получить быстрый снимок того, что он делает. Вы можете запустить это без явной установки.

Кроме этого, полный дамп + windbg + SOS дает вам больше информации, но получить ее не тривиально.