Как я вижу код c #, который вызвал сбой в clr.dll? - PullRequest
1 голос
/ 23 июля 2010

У меня есть приложение Windows Forms (.NET 4), которое отлично работает на моей машине для разработки, но дает сбой на двух других тестовых машинах.Я могу загрузить мини-дамп, который он создает в VS2010.

Выбор «Отладка со смешанным» приводит к, по-видимому, бесконечному (я убил devenv примерно через 20 минут) злоупотреблению ЦП Visual Studio.

Когда я «Отлаживаю только с помощью Native», он не может найти источник (даже если я отразил источник в той же папке, что и на тестовой машине).Он просто говорит:

Необработанное исключение в 0x793f5b8c в YourWinApp .exe.hdmp: 0xC0000409: 0xc0000409.

И затем показывает мне

Расположение стека вызовов: clr.dll! 793f5b8c ()

Как узнать, что вызывает сбой приложения?Могу ли я выполнить полную аварийную остановку во время отображения диалогового окна «Уведомить Microsoft», и это поможет?

Ответы [ 2 ]

5 голосов
/ 23 июля 2010

Отладка Minidump должна была быть значительно улучшена в VS2010.Сам пока не видел много доказательств, отладка в смешанном режиме выглядит так же неловко, как и раньше, когда я проводил несколько быстрых тестов.Не верьте мне на слово, хотя.Тем не менее, «только для родного» никогда не покажет вам управляемый стек вызовов.

Решите это в источнике.Напишите обработчик события для AppDomain.CurrentDomain.UnhandledException и зарегистрируйте его в своем методе Main ().Пусть он отображает значение e.ExceptionObject.ToString () в, скажем, окне сообщения.Это дает вам трассировку управляемого стека исключения.Несмотря на то, что отображается это окно сообщения, вы также можете привязать мини-дамп, чтобы приблизить вас к месту сбоя.

Однако конкретное исключение, которое вы получаете, определенно указывает на собственный код C / C ++.Переполнение буфера, повреждающее стек.Убедитесь, что у вас есть файлы .pdb для любого собственного кода, используемого вашим приложением.И настройте сервер символов Microsoft таким образом, чтобы вы получали хорошую трассировку собственного стека из минидампа.

Редактировать: тот факт, что вы не получили UnhandledException, определенно указывает на проверку целостности стека в CRT.Он был разработан, чтобы не вызывать исключение, но немедленно завершать программу.Необходимое поведение из-за того, что стек скомпрометирован, код не может предположить, что его можно безопасно развернуть.Учитывая место сбоя, вполне вероятно, что эта проверка фактически выполняется в коде CLR.Я знаю, что это не было сделано в предыдущих версиях CLR, но это может отличаться в версии CLR, включенной в .NET 4.0

. Это затруднит получение трассировки управляемого стека.Существует много возможностей для обратного инжиниринга из трассировки неуправляемого стека, если вы настроите сервер символов так, чтобы вы получали имена идентификаторов из фреймов стека CLR.Опубликуйте эту трассировку стека в своем вопросе, если вам нужна помощь в ее интерпретации.Кстати, ошибка в коде CLR не исключена, вы можете обратиться в службу поддержки Microsoft.Им, однако, потребуется последовательное воспроизведение.Они могут обойтись этим важным отслеживанием стека, если репозиторий трудно найти.Настройте сервер символов, чтобы получить хорошую трассировку неуправляемого стека.Easy in VS2010: Инструменты + Параметры, Отладка, Символы, отметьте «Серверы Microsoft Symbol».

0 голосов
/ 27 июля 2010

Вы настраиваете procdump для получения полного дампа памяти, если в приложении есть необработанное исключение, которое вы можете отладить в VS или Windbg

А у мини-дампов есть информация о стеке вызовов в виде групп Уотсона, вот один из команды CLR , и я писал о той же

Краткое объяснение информации о корзине Ватсона, которую вы видите в средстве просмотра событий для необработанного исключения

  1. ExeFileName
  2. Версия сборки Exe
  3. Временная метка сборки Exe
  4. ФИО
  5. Версия с ошибочной сборкой
  6. Временная метка неправильной сборки
  7. Неисправный метод сборки def
  8. Ошибка инструкции IL, вызвавшей исключение
  9. Тип исключения
...