Анализ аварийных дампов
 

Поскольку ошибки, приводящие к BSOD, это частая тема для обсуждения, выносим ее в отдельный тред. Флуд на тему кривая виндовс, бил гейц мудак, не приветствуется. Да будет известно что 95% ошибок происходит из-за стороннего по, оборудования и т.д. Ветка техническая и всякий мусор буду просить администрацию удалять.

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


Инструменты:

1. WinDbg из пакета Debugging Tools for Windows. Скачать можно здесь http://www.microsoft.com/whdc/devtools/debugging/default.mspx. Есть альтернативы но я не рекомендую по причине того, что мощнее его наверное нет.
2. VmWareWorkstation (Виртуальная машина) – понадобится нам для изучения внутреннего устройства Windows, отладки своего кода на предмет ошибок и т.д. Есть альтернативы, например Microsoft Virtual PC, VirtualBox и т.д.
3. NotMyFault – программа для искусственного создания краха системы. Нужна для образовательных целей.
4. Дизассемблер – любой, я использую IdaPro.

Литература:

1. «Внутреннее устройство Microsoft Windows» – глава «Анализ аварийного дампа».
2. http://www.dumpanalysis.org/blog/ - сайт непосредственно по анализу. Англ.
3. http://blogs.msdn.com/b/ntdebugging/ - сайт по отладке включая и анализ аварий. Англ.
4. http://www.nynaeve.net/ - по отладке и куча ссылок на другие источники. Англ.
5. http://www.google.com.ua/ Рус.

Теоретические сведения.

Пока только самое простое. Как загрузить дамп в WinDbg, какие виды дампов бывают, где и как хранятся, как настроить.

Типы дампов. Фактически копипаст из книги «Внутреннее устройство Microsoft Windows».

Complete memory dump (Полный дамп памяти) – представляет собой содержимое всей физической памяти (ОЗУ) на момент краха. Тобишь если у вас установлено 1 Гб ОЗУ, дамп будет такого объема + служебная инфа, поэтому надо позаботиться, чтобы на системном томе всегда было место.

Kernel Memory Dump (Дамп памяти ядра) – это дамп содержит только память, которую занимало ядро и драйверы на момент аварии (без пользовательских программ). Размер дампа заранее неизвестен, так как неизвестно сколько на момент сбоя памяти принадлежало ядру.

Small memory dump (малый дамп памяти) он же минидамп. Он включает в себя минимальную информацию об ошибке, точнее ту же информацию что и в других дампах, но памяти в нем хранится буквально несколько килобайт(страниц). Размер 64 кб и 128 в 64-разрядных системах.

Какой из дампов генерировать, настраивается через аплет свойства системы-дополнительно-загрузка и восстановление, либо через реестр. Сохраняются дампы в каталог Windows, в файл Memory.dmp и каждый новый будет перезаписывать его. Минидампы хранятся в Windows\Minidump и не перезаписываются.

Открывается файл дампа в Windbg через меню File-OpenCrashDump, после чего вы увидите краткую информацию о системе, и багчек. Для того чтобы Windbg детальнее разобрал содержимое дампа нужно использовать команду !analyze–v.

Пока все, пост будет редактироваться.

Хорошо, значит если я в настройках выбираю "полный дамп ядра", то мне надо что бы на диске С было свободного места ровно столько сколько физ. ОЗУ и даже желательно больше, и потом система восстановится и все те данные до момента синего экрана (там страница IE, документ офис, и тг) восстановятся или как?
п.с:билл гейц мудак

Тяжелый случай...

З.Ы. Просили же...

Нет, дамп. Это слепок системы перед уходом в BSOD (синий экран ошибки).
Кстати есть сайты, так же которые дают описание кода BSOD 0x00007b например :)

аварийные дампы не имеют отношения к восстановлению файлов.

Что то замерла тема, будет еще какое нить продолжение?

Предложи тему для продолжения

все зависит от ваших вопросов и интереса.

Могу рассказать про реконструкцию стэка вызовов(call stack). Часто приложения падают по причине того, что одна из функций затирает некоторые данные в стэке, в следствии чего невозможно проследить call stack (последовательность вызовов функций) автоматизированными средствами отладчика.