Отладка мини-дампа в Visual Studio, где стек вызовов является пустым
У меня есть клиент, который получает 100% reproduceable катастрофический отказ, что я не могу копировать в своей программе, скомпилированной в Visual Studio 2005. Я отправил им отладочную сборку своей программы и сохранил весь PDB и файлы DLL удобными. Они отправили мне файл мини-дампа, но когда я открываю его, я добираюсь:
"Необработанное исключение в 0x00000000 в MiniDump.dmp: 0xC0000005: местоположение чтения Нарушения прав доступа 0x00000000".
Затем стек вызовов показывает только "0x00000000 ()", и дизассемблирование показывает мне дамп памяти в 0x0. Я настроил сервер символов, загрузили мои символы PDB, и т.д. Но я не вижу способа знать, какой из многих DLLs на самом деле вызвал переход к пустому указателю. Это - крупный проект со многими зависимостями, и некоторые из них являются двоичными файлами, для которых у меня нет источника или PDBs, поскольку я использую API в качестве третьей стороны.
Таким образом, как же этот мини-дамп полезен? Как я вижу, который DLL вызвал катастрофический отказ? Я действительно никогда не использовал мини-дампы для отладки прежде, но все учебные руководства, которые я прочитал, кажется, по крайней мере, отображают имя функции или что-то еще, что дает Вам ключ к разгадке в стеке вызовов. Я просто получаю одну строку, указывающую на пустой указатель.
Я также пытался использовать, "Зависит", чтобы видеть, была ли некоторая зависимость DLL, которая была не разрешена; однако на моих трех тестовых машинах с различным Windows ОС, я, кажется, получаю три различных набора ОС зависимости DLL (и все же не может копировать катастрофический отказ); таким образом, это не кажется особенно надежным методом ни один для диагностирования проблемы.
Что другие методы доступны для определения причины этой проблемы? Там некоторый путь состоит в том, чтобы отступить одна инструкция видеть, который DLL перешел к пустому указателю?
5 ответов
Вся идея всех "простых" способов посмертной отладки заключается в захвате трассировки стека. Если ваше приложение перезаписывает стек, то такой анализ невозможен. Помочь могут только очень сложные методы, которые записывают все выполнение программы на специальном оборудовании.
В этом случае лучше всего использовать лог-файлы. Разложите несколько записей журнала очень широко вокруг области, где происходит сбой, и передайте эту версию клиенту. После сбоя вы увидите последнее сообщение журнала в вашем файле журнала. Добавьте еще выписки из журнала между этой точкой и следующей выпиской, которая не была записана в файл журнала, снова отправьте эту версию. Повторяйте, пока не найдете строку, вызывающую проблему.
Я написал об этом статью из двух частей на ddj.com:
Просто наблюдение, но стек усекается или перезаписывается, может быть, это простой случай использования неинициализированного поля или, возможно, буфера переполнение?
Это может быть довольно легко найти.
Пробовали ли вы установить WinDbg на компьютер клиента и использовать его в качестве отладчика по умолчанию для любого приложения, вызывающего сбой? Вам просто нужно добавить файлы pdb в папку, где находится ваше приложение. Когда происходит сбой, WinDbg запускается, и вы можете попытаться получить стек вызовов.
Возможно, вы уже знаете это, но вот некоторые моменты, касающиеся отладки минидампа: 1. У вас должны быть точно такие же исполняемые файлы и PDB-файлы, как на клиентском компьютере, где был создан minidump, и они должны быть размещены точно в тех же каталогах. Простое восстановление той же версии не поможет. 2. Отладчик должен быть подключен к серверу MS Symbols. 3. Когда отладчик запускается, он печатает журнал загрузки процесса в окне Output. Как правило, все библиотеки должны быть успешно загружены с отладочной информацией. Библиотеки без отладочной информации также загружаются, но печатается "no debug info". Изучите этот журнал - он может дать вам некоторую информацию.
Если исполняемый стек содержит кадры из библиотеки без отладочной информации, он может быть не показан. Это происходит, например, если ваш код выполняется как обратный вызов сторонней библиотеки.
Попробуйте создать минидамп на своем компьютере, добавив в него код, который создает необработанное исключение, и сразу же отладить его. Работает ли это? Сравните журнал загрузки в успешном и неуспешном сеансах отладки.
Что ж, похоже, что ответ в этом случае был «Используйте WinDbg вместо Visual Studio для отладки минидампов». Я не мог получить какую-либо полезную информацию из VS, но WinDbg предоставил мне обширную информацию о цепочке вызовов функций, которые привели к сбою.
В этом случае это все еще не помогло решить мою проблему, так как все функции были в сторонней библиотеке, которую я использую, поэтому похоже, что единственным окончательным ответом на мою конкретную проблему является использование файлов журнала для отслеживания состояние моего приложения, которое приводит к сбою.
Думаю, если кто-нибудь еще увидит аналогичную проблему с бесполезным стеком вызовов при отладке минидампа, лучше всего открыть его с помощью WinDgb, а не Visual Studio. Кажется странным, что лучший инструмент для работы - это бесплатный продукт Microsoft, а не коммерческий.
Другой урок здесь, вероятно, заключается в том, что «любая программа, использующая стороннюю библиотеку, должна писать файл журнала».