Длинная (скучная) история
В настоящее время у меня есть приложение, которое приводит к исключению только на одном компьютере. После нескольких копаний я мог бы заключить проблему в небольшой пример приложения, но истинная причина все еще скрывается.
В связи с тем, что на этом компьютере не установлена Visual Studio, и мы не можем этого сделать, я искал другое решение, чтобы найти истинную причину.
В первом подходе я все больше и больше разбирал свое маленькое приложение, просто внимательно прочитав сообщение об исключении, сравнив его с кодом и попыткой & ошибкой, чтобы прийти к конкретной проблеме. Но это не поможет получить всю информацию о текущих значениях всех используемых переменных и т. Д.
Так что я искал другой лучший способ получить необходимую мне информацию. Я уже давно читал о дампах и мини-дампах , но они мне никогда не нужны, потому что до сих пор я всегда мог воспроизвести описанный пользователем сценарий на моем компьютере разработчика или тестовой машине.
Но на этот раз, похоже, проблема возникла только на одном компьютере, и, к сожалению, изменить всю машину или установить все новое невозможно.
Чтобы узнать, как работать с дампами, я просто написал простое тестовое приложение на c #, содержащее одну кнопку, которая не выполняет ничего, кроме throw new ArgumentException("Test");
Теперь мне нужно создать такой волшебный файл дампа после нажатия вредоносной кнопки, прочитать его в Visual Studio 2008 Professional и посмотреть на него, как на обычное работающее приложение в VS, за исключением того, что Step next и т. Д. не сработает.
Насколько мне известно, лучший инструмент для создания дампа в определенный момент времени - это procdump , так как вы можете определить, когда будут взяты один или несколько дампов.
Так что я просто скачал его и запустил, позвонив procdump -o -e MyApp.exe d:\MyApp.dmp. Он утверждает, что MyApp.exe не существует. Ладно моя вина Просто сначала запустите MyApp, а затем выполните procdump.
Procdump запущен, теперь показывает мне все свои опции, которые он использует, и, похоже, ожидает необработанное исключение. Нет ничего проще, я просто нажимаю свою вредоносную кнопку ... и ничего не происходит в procdump.
Вместо этого появляется диалоговое окно из моего приложения, которое объясняет, что произошло необработанное исключение (сюрприз, сюрприз) и что я хотел бы сделать (Детали, Продолжить, Выйти). Но независимо от того, что я выбрал, procdump не может автоматически создать файл дампа.
Если я пойду и просто позвоню procdump -o MyApp.exe d:\MyApp.dmp, когда диалоговое окно показывает, что файл дампа кажется бесполезным, то после открытия его в VS стек вызовов просто висит где-то в ntdll.dll, но нигде в моем коде (я предположил бы, что это MessageQueue диалога, ожидающего несколько щелчков мыши).
Если я поближе рассмотрю детали, вы найдете некоторую информацию о том, как делегировать необработанное исключение JIT-отладчику. Но я не хочу JIT-отладчик, я бы хотел завершить работу приложения, чтобы получить файл дампа.
После этих попыток я обнаружил ClrDump , но это не дало лучших дампов (если я загружу его в VS и посмотрю на стек вызовов).
С учетом этой информации вы (надеюсь) теперь можете предоставить мне (рабочее) решение для моего приложения .Net:
(короткий) вопрос
Как я могу создать файл дампа, когда в приложении .net возникает необработанное исключение, что я могу загрузить файлы MyApp .pdb и посмотреть, при каких обстоятельствах возникло исключение?
Ответ
С помощью Навина и Лекса Ли я смог немного лучше понять, как работает отладка с помощью аварийных дампов. А теперь я просто хочу напомнить все, что нужно, чтобы заставить его работать:
Всякий раз, когда вы хотите получить дамп процесса, вы можете выбрать один из нескольких инструментов для выполнения работы:
- ProcDump
- простой инструмент командной строки, который может создавать дампы в сложных сценариях, но он не работает для перехвата .net необработанных исключений.
- DebugDiag
- простой графический инструмент, который может создавать дампы при сбоях (даже .net исключений), но не может создавать дампы в сложных сценариях, таких как Procdump.
Как видите, вы получите два инструмента, которые способны создавать дампы при разных обстоятельствах, поэтому оба они больше партнеров, чем конкурентов в создании дампов в нужный момент времени.
ПослеПри создании дампа с помощью одного из вышеперечисленных инструментов самое время проанализировать дамп, чтобы выяснить причину проблемы.Для анализа вы можете взять WinDbg.Он является частью Средства отладки для Windows и может быть получен от Microsoft.К сожалению, входной барьер WinDbg довольно высок, но он действительно мощный.Возможно, загляните в этот блог , чтобы лучше понять, как использовать этот инструмент.
Если у вас есть приложение .Net 4 и вы используете Visual Studio 2010, вы также можете использовать его дляанализирующая.Его намного проще использовать благодаря лучшему графическому интерфейсу пользователя, но он не обладает мощью WinDbg.Чтобы получить лучшее сравнение, вы должны взглянуть на эту статью .
И последнее, но не менее важное: вы также можете использовать sos.dll в Visual Studio 2008. Вотстатья с описанием того, что вы можете с ней сделать.