диалоговое окно аварийного завершения работы доктора Уотсона при закрытии приложения .NET 2.0

Question

При выходе из процесса иногда появляется диалоговое окно с аварийным завершением dr watson. Процесс .NET 2.0. диалог не очень полезен. Это говорит о том, что процесс перестал работать и в деталях Я вижу, что речь шла о System.NullReferenceException, отлично, но где же трассировка?

Обычно при возникновении ошибки в процессе .net трассировка выводится на стандарт ошибка. Но не в этом случае, вероятно, из-за выхода из процесса. Кто-нибудь может дать мне указатели о том, как получить больше информации о причине сбоя, когда этот диалог появился?

Answer 1

Я склонен отключить Dr Watson на компьютерах разработчиков и использовать Visual Studio как отладчик времени, который запускается при бомбардировке приложения. Я считаю этот способ более полезным с точки зрения анализа первопричин, особенно если у вас есть доступная информация об отладке.

Answer 2

Я использую DILE для отладки приложений на производственных серверах.

Dotnet IL Editor (DILE) позволяет разбирать и отлаживать .NET Приложения 1.0 / 1.1 / 2.0 / 3.0 / 3.5 без исходного кода или файлов .pdb. Он может отлаживать даже сам или сборки .NET Framework на IL уровень.

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

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

Answer 3

Если сбой воспроизводим, возможно, стоило бы настроить отладчик на прерывание всех исключений (возможно, как собственных, так и CLR) перед закрытием приложения. Часто сбой может быть вызван более ранней ошибкой, так что это может дать вам подсказку.

Вы смотрели файлы дампа доктора Ватсона? Обычно они должны сказать вам, по крайней мере, какой модуль вызвал проблему. Если бы вы имели дело с нативным кодом, вы могли бы загрузить файл мини-дампов, предоставленный доктором Уотсоном, в Visual Studio, и, имея на этом компьютере файлы с отладочными символами и исходным кодом, вы сможете увидеть состояние вашего приложения по адресу время сбоя, стек вызовов ошибочного потока и строка кода, которая вызвала сбой. Я понятия не имею, что происходит с управляемым кодом, но, возможно, стоит попробовать.

Эта ссылка должна дать вам больше информации об анализе файлов мини-дампов. Ссылка на CodeProject

Answer 4

Присоединить с помощью WinDBG. По всей вероятности, исключение возникает в неуправляемом коде.