    
Раздел: Документация
0 ... 87 88 89 90 91 92 93 ... 102 1.Копию голубого экрана. 2.Перечень загруженных драйверов. 3.Контекст обрушившегося процесса со всеми его потоками. 4.Первые 16 Кбайт содержимого ядерного стека обрушившегося потока. Разочаровывающс малоинформативиые сведения! Непосредственный анализ дампа дает нам лишь адрес возникновения ошибки и имя драйвера, к которому этот адрес принадлежит. При условии, что конфигурация системы не была изменена после возникновения сбоя, мы можем загрузить отладчик и дизассемб-лировать подозреваемый драйвер, по это мало что даст. Ведь содержимое сегмента данных на момент возникновения сбоя нам неизвестно, более того — мы не можем утверждать, что видим те же самые машинные команды, что вызвали сбой. Поэтому малый дамп памяти полезен лишь тем, кому достаточно одного имени нестабильного драй вера. Как показывает практика, в подавляющем большинстве случаев этой информации действительно оказывается вполне достаточно. Разработчикам драйвера отсылается гневный бан-рапорт (вместе с дампом!), а сам драйвер тем временем заменяется другим — более новым и надежным. По умолчанию малый дамп памяти записывается в директорию %SystemRoot%\Minidump, где ему присваивается имя Mini, дата записи дампа и порядковый номер сбоя на данный день. Например, MinillO701-69.dmp — 69-ii дамп системы от 07 ноября 2001 года. ДАМП ПАМЯТИ ЯДРА Дамп памяти ядра содержит более полную информацию о сбое и включает в себя всю память, выделенную ядром и его компонентами (драйверами, уровнем абстракции от оборудования и т. д.), а также копию экрана смерти. Размер дампа памяти ядра зависит от количества установленных драйверов и варьируется от системы к системе. Контекстная помощь утверждает, что эта величина составляет от 50 до 800 Мбайт. Ну, на счет 800 Мбайт авторыявно загнули, и объем в 50-100 Мбайт выглядит более вероятным (техническая документация на систему сообщает, что ориентировочный размер дампа ядра составляет треть объема физической оперативной памяти, установленной па системе). Это наилучший компромисс между накладными расходами на дисковое пространство, скоростью сброса дампа и информативностью последнего. Весь джентльменский минимум информации — в вашем распоряжении. Практически все типовые ошибки драйверов и прочих ядерных компонентов могут быть локализованы с точностью до байта, включая и те, что вызваны физическом сбоем аппаратуры (правда, для этого вы должны иметь некоторый патологоанатомн-ческий опыт исследования «трупных» дампов системы). По умолчанию дамп памяти ядра записывается в файл %SystemRoot%\Memory.dmp, затирая пли не затирая (в зависимости от текущих настроек Системы) предыдущий дамп. ПОЛНЫЙ ДАМП ПАМЯТИ Полный дамп памяти включает в себя все содержимое физической памяти компьютера, занятое как прикладными, так и ядерными компонентами. Полный дамп памяти оказывается особенно полезным при отладке ASPI/SPTI- приложений, которые в силу своей специфики могут уронить ядро даже с прикладного уровня. Несмотря на довольно большой размер, равный размеру оперативной памяти, полный ламп остается наиболее любимым дампом всех системных программистов (системные же администраторы в своей массе предпочитают малый дамп). Это не покажется удивительным, если вспомнить, что объемы жестких дисков давно перевалили за отметку 100 Гбайт, а оплата труда системных программистов за последние несколько лет даже возросла. Лучше иметь невостребованный полный дамп под рукой, чем кусать локти при его отсутствии. По умолчанию полный дамп памяти записывается в файл %Sys-temRoot%\Memory.dmp, затирая пли не затирая (в зависимости от текущих па-строек Системы) предыдущий ламп. Выбрав предпочтительный тип дампа, давайте совершим учебный урон системы, отрабатывая методику его анализа в полевых условиях. Для этого нам понадобится: 1.Комплект разработчика драйверов (Driver Development Kit или сокращенно DDK), бесплатно распространяемый фирмой Microsoft и содержащий и себе подробную техническую документацию по ядру системы; несколько компиляторов Си/Си++ и ассемблера, а также достаточно продвинутые средства анализа дампа памяти. 2.Драйвер W2K KILL.SYS или любой другой драйвер-убийца операционной системы, например, BDOS.EXE от Марка Русиновича, позволяющий получить дамп в любое удобное для нас время, не дожидаясь возникновения критической ошибки (бесплатную копию программы можно скачать с адреса http:/ /www.sysinternals.com ). 3.Файлы символьных идентификаторов (symbol files), необходимые отладчикам ядра для его нормального функционирования и делающие дизассемб-лерпып код более наглядным. Файлы символьных идентификаторов входят в состав «зеленого» набора MSDN, но, в принципе, без них можно и обойтись, однако переменная окружения NTSYMBOLPATH по-любому должна быть определена, иначе отладчик i386kd.exe работать не будет (последние версии kernel debiiggera поддерживают возможность загрузки символьной информации по требованию, динамически загружая се с удаленного сервера, для этого переменная NTSYMBOLPATH должна быть определена следующим образом: SRV*C:\WINNT\Symbols\*http://msdI.microsoft.com/downIoad/ symbols, что особенно полезно тем, кто сидит на топких диалапнутых каналах, вместо того, чтобы сливать полный символьный набор, весящий свыше 100 Мбайт и требующий 1 Гбайт дискового пространства, теперь можно скачивать лишь действительно нужные символы (как правило, это символы ядра) с общим объемом -100 Кбайт). 4- Одна или несколько книжек, описывающих архитектуру ядра системы. Очень хороша в этом смысле «Внутреннее устройство Windows 2000» Марка Русснновича и Дэвида Соломона, интересная как системным программистам, так и администраторам (о том, что большая часть книги нагло передрана с бессмертного творения Хелен Кастер «Основы Windows NT», мы скромно промолчим). Итак, установив DDK на свой компьютер и завершив все приложения, запускаем драйвер-убийцу, и... под скрипящий звук записывающегося дампа система немедленно выбрасывает голубой экран, кратко информирующий нас о причинах сбоя (лпстингА. 19). Листинг А.19. Свидетельство возникновения неустранимого сбоя системы с краткой информацией о нем на голубом экране смерти (BSOD — Blue Screen Of Death) *** STOP: 0x000000It" (0x00000005. OxBEBOBOOO. 0x00000000. 0x00000000) KM0DE EXEPT10N N0T HALTED *** Address OxBE80BOOO base at 0xBE80A000. Date Stamp 389db915 - w2k kil.l .sys Beginning dump of physical memory Dumping pnysicai memory to disk: 69 Для большинства администраторов голубой экран означает лишь одно — системе «поплохело» настолько, что она предпочла смерть позору неустойчивого функционирования. Что же до таинственных письмен — они остаются сплошной загадкой. Но только не для настоящих профессионалов! Мы начнем с левого верхнего угла экрана и, зигзагами спускаясь вниз, трассируем все надписи по порядку: •*** STOP: — буквально означает «останов (системы)» и не несет в себе никакой дополнительной информации: •0х0000001Е — представляет собой Bug Check-код, содержащий категорию сбоя. Расшифровку Bug Check-кодов можно найти в DDK. В данном случае это OxlE - KMODE EXEPTION NOT HALTED, о чем и свидетельствует символьное имя, расположенное строкой ниже. Краткое объяснение некоторых наиболее популярных Bug Check-кодов приведено в таблице А.1. Полноту фирменной документации она, разумеется, не заменяет, но некоторое представление о Целесообразности скачивания 70 метров DDK все-таки дает; •арабская вязь в круглых скобках — это четыре Bug Check-параметра, физический смысл которых зависит от конкретного Bug Check-кода и вне его контекста теряет всякий смысл. Применительно к KM0DE EXEPTI0N NOTHALTED — первый Bug Check-параметр содержит номер возбужденного исключения. Судя потабл. А.1,это - STATUSACCESSVIOLATION -доступ к запрещенному адресу памяти — и четвертый Bug Check-параметр указывает, какой именно. В данном случае он равен нулю, следовательно, некоторая машинная инструкция попыталась совершить обращение по null-pointer, соответствующему инициализированному указателю, ссылающемуся на невыделенный регион памяти. Ее адрес содержится во втором Bug Check-параметре. Третий Bug Check-параметр в данном конкретном случае не определен; •*** Address 0хВЕ80В00 — это и есть тот адрес, по которому произошел сбой. В данном случае он идентичен второму Bug Check-параметру, однако так бывает далеко не всегда (Bug Check-коды, собственно, н не подряжались хранить чьи-либо адреса). •base at 0хВЕ80А00 — содержит базовый адрес загрузки модуля-нарушителя системного порядка, по которому легко установить «паспортные» данные-самого этого модуля (внимание: далеко не во всех случаях правильное опре- 0 ... 87 88 89 90 91 92 93 ... 102 |
