1. Вы находитесь в архивной версии форума xaker.name. Здесь собраны темы с 2007 по 2012 год, большинство инструкций и мануалов уже неактуальны.
    Скрыть объявление

Процесс поиска неисправности BSOD

Тема в разделе "Other Windows", создана пользователем ozs, 30 дек 2010.

  1. ozs

    ozs ... Модератор

    Регистрация:
    25 дек 2007
    Сообщения:
    566
    Симпатии:
    390
    Баллы:
    0
    "Синий" экран (или "синий экран смерти", "синий" экран гибели, или BSOD) известен как "Windows Stop Message”. Данная ошибка появляется на экране, когда ядро Windows или драйвер, работающий в режиме ядра сталкиваются с ошибкой, которая не может быть обработана. Эта ошибка может быть чем-то подобным процессу или драйверу, пытающемуся получить доступ к адресу памяти, в который у него нет доступаразрешения получить доступ, или пытающийся записать в раздел памяти, который отмечен только для чтения.

    Самое главное, Stop Message не происходят без причины; они - признак, что у системы где-то есть проблема – аппаратные средства, программное обеспечение, или драйверы устройства. Часто простая перезагрузка вернет систему в работоспособное состояние, но если основная проблема не будет решена, то "синий" экран, вероятно, возвратится снова.

    Цель этой статьи состоит в том, чтобы предложить методический подход к поиску неисправностей, с несколькими простыми шагами.

    Шаг 1 – Чтение сообщения


    Это может казаться очевидным, но на первом шаге вы должны просто прочитать сообщение, выведенное на экран. Часто там есть достаточная информация, чтобы указать Вам на причину – если ошибка остановки вызвана драйвером, название драйвера показывается в сообщении.

    [​IMG]

    DRIVER_IRQL_NOT_LESS_OR_EQUAL”. Эта ошибка вызвана, когда драйвер в режиме ядра попытку незаконного доступа к памяти. Раздел “Technical information” показывает код ошибки, и также указывает на определенный драйвер, который вызвал ошибку – в этом случае это - “myfault.sys”, который является драйвером, установленный утилитой Sysinternals NotMyFault.exe , которую я использовал для создания данной ошибки. В реальном сценарии название драйвера может быть любым, установленным на системе, но как только вы знаете название драйвера, вы можете найти его и получить сведения о его производителе.

    [​IMG]

    С точки зрения быстрого решения проблемы вы можете поискать обновленный драйвер на сайте производителя или поискать в доступные решения этой проблемы в базе знаний. Однако, не каждое сообщение расшифровывается так легко - иногда сведений об ошибки довольно мало.

    [​IMG]

    Хотя это сообщеине выглядит довольно спартанским, здесь все ещё есть немного полезной информации – раздел “Technical Information” включает код остановки (0x0000007B в рисунке 3), и иногда этого может быть достаточно, чтобы начать поиск неисправностей. Однако, независимо от того знаете ли вы как решить данный код остановки, мы перемещаемся в шаг 2: Поиск.


    Шаг 2 – Поиск

    Если сообщение об ошибке не дало достаточную информацию, чтобы решить проблему немедленно, следующий шаг должен заключаться в поиске дополнительный деталей. Это может казаться очевидным, но в моих интервью я был также удивлен числом людей, которое не упоминули, что они будут использовать базу знаний Microsoft, Microsoft TechNet, MSDN, или некоторые другие ресурсы онлайн, расследуя причины ошибок "синего" экрана.

    Например, быстрый поиск по MSDN или TechNet покажет, что код остановки, показанный в рисунке 3, 0x0000007B, расшифровывается как INACCESSIBLE_BOOT_DEVICE, что означает, что операционная система была не в состоянии инициализировать устройство хранения данных, с которого она пытается загрузиться во время системной инициализации ввода / вывода. Это вообще указывает на проблему драйвера устройства хранения, и знание того, что проблема вызвана подсистемой хранения, помогает сосредоточиться на поиске неисправностей в определенной области.

    Есть много, очень много веб-сайтов, предлагающих помощь в поиске неисправностей ошибок остановки. Я предпочитаю всегда начинать с сайтов Microsoft или сайтов продавца аппаратных средств, затем расширяю мой поиск на другие сайты и форумы, если я не могу найти то, в чем я нуждаюсь. В большинстве случаев, кто-то еще испытает ту же самую проблему, и могут быть решения или предлагаемые обходные пути.

    Конечно, оба шага полагаются на одну решающую вещь – что Вы засвидетельствовали и/или сделали запись сообщения остановки. Если вы не видели, что сообщение остановки происходит, то вы можете найти ошибку остановки и параметры в системном журнале событий, но к сожалению нет никаких дополнительных деталей, таких как след стека. Однако, даже с деталями сообщения остановки, все еще, возможно, нет достаточной информации для заключительного диагноза, и в этом пункте мы должны идти дальше и присупить к шагу 3: анализ дампа отказа.

    Шаг 3 – Анализ
    Третий и заключительный метод в моем подходе заключается в выполнении анализ файла дампа отказа, который по умолчанию настроен на создание во всех Windows системах. . Есть три типа файла дампа отказа, и настройки управления тем, какой тип файлов создается, может быть найден на вкладке Advanced в окне System Properties.

    [​IMG]


    Полный Дамп Памяти

    Полный дамп памяти содержит все данные, которые были в физической памяти во время катастрофического отказа. Полные файлы дампа требуют, чтобы файл страницы существовал на системном диске, и что он имеет размер по крайней мере равный размеру физической памяти плюс 1 МБ. Поскольку полные дампы памяти могут быть очень большими, они автоматически скрыты от пользователя на системах больше чем с 2GB физической памяти, хотя это может быть переопределено с помощью изменения реестра.
    Дамп Памяти ядра

    Дамп памяти ядра содержит страницы чтения-записи режима ядра, которые были в физической памяти во время отказа. Файл дампа также содержит список выполнения процессов, стек текущего потока, и списка загруженных драйверов устройства. Дампы памяти ядра - значение по умолчанию в Windows Server 2008 и Windows 7.
    Малый Дамп Памяти

    Маленький дамп памяти (иногда также названный минидампом) содержит код ошибки остановки и так же как список загруженных драйверов устройств, и небольшое количество других данных. Малые дампы памяти очень сложно анализировать на системе, отличной от той, в которой он был создан.

    Для анализа отказа дамп памяти ядра создается в местоположение по умолчанию - %SystemRoot %\MEMORY.DMP. Инструментом, требуемым для того, чтобы проанализировать файл дампа отказа, является WinDbg, Microsoft Windows Debugger, который может быть загружен с веб-сайта Microsoft.

    После установки WinDbg должен быть сконфигурирован, чтобы использовать Microsoft Symbol Server. Как только символы сконфигурированы, щелкните по меню File, выберите Open Crash Dump, и укажите файл дампа отказа, который Вы хотите проанализировать. Вывод от WinDbg будет похож на это:
    [​IMG]
    Вторая с конца сторока, которая начинается со слов "Probably caused by” указывает, что отладчик предполагает причиной отказа. В примере в рисунке 5 отладчик нашел проблему правильно - этот отказ был вызван NotMyFault. Другая информация в анализе указывает, что файл дампа отказа - дамп памяти ядра, и что файлы символа не могли быть загружены для myfault.sys (потому что это - сторонний драйвер, и символы не доступны на Microsoft Symbol Server).

    Больше информации может быть получено из файла дампа, если вы выполните подробный анализ, используя команду отладчика !analyze -v.
    [​IMG]

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

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

    Для начала рекомендую использовать отличный веб-сайт Debugging Tools for Windows , а также книгу “Windows Internals" (в настоящее время выпущена 5-ая редакция ) Марка Руссиновича, которая включает подробную главу по анализу дампа отказа.

    (c)guruadmin.ru


    Раскрашиваем BSOD

    Наблюдение BSoD с цветом, отличающимся от синего может смутить кого угодно, даже меня, и, основываясь на реакции аудитории TechEd, я готов поспорить, что вам было бы интересно подобрать свой цвет и потом показать его своим друзьям-айтишникам. Впервые я увидел это в исполнении Дэна Пирсона (Dan Pearson) во время его беседы о диагностике аварийных дампов памяти, которую он вел несколько лет назад с Дэйвом Соломоном (Dave Solomon), и теперь я завершаю свои презентации из серии «Дело о …» BSoD’ом в выбранном аудиторией цвете (реакцию аудитории на подобную концовку вы можете услышать, например, в конце этого видео). Стоит отметить, что описанные мной шаги для изменения цвета BSoD проделываются вручную и затрагивают только сеанс загрузки, так что они подходят для демонстраций, а не для общей настройки BSoD. Обязательно взгляните на специальный праздничный экран смерти, который я приготовил для вас в конце этого сообщения.

    Подготовка системы​


    Поскольку нам придется изменить код ядра, первый шаг заключается в разрешении редактировать код ядра в памяти, если это ранее не было сделано. Системы Windows с менее чем 2 Гб ОЗУ используют страницы объемом 4 Кб для хранения кода ядра, благодаря чему можно обеспечить необходимый уровень защиты для содержимого. Например, страницы данных ядра должны разрешать доступ на чтение и запись, в то время как код ядра должен предоставлять доступ только для чтения и выполнения. В рамках оптимизации, которая позволяет увеличить скорость трансляции виртуальных адресов, Windows использует большие страницы (4 Мб на x86 и x64) на больших системах. Это означает, что если в странице хранится и код, и данные, то эта страница должна представлять доступ на чтение, запись и выполнение; так что для того, чтобы гарантировать возможность редактирования страницы, вы должны обеспечить использование Windows больших страниц. Если у вас Windows XP или Windows Server 2003 и менее 256 Мб ОЗУ, или Windows Vista или старше и есть 2 Гб ОЗУ или меньше, создайте значение REG_DWORD с названием LargePageMinimum, которое установлено в 1, в ветке реестра HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management:

    [​IMG]
    Чтобы вам не надо было спешить похвастаться результатами своей работы пока Windows автоматически не перезагрузится после сбоя, измените настройки автоперезагрузки. На Windows XP и Server 2003 щелкните правой кнопкой мыши на значке «Мой компьютер», выберите вкладку «Дополнительно» и нажмите кнопку «Параметры» в разделе «Загрузка и Восстановление». На Windows Vista и выше щелкните правой кнопкой мыши на значке «Компьютер» в меню Пуск, выберите «Свойства», нажмите «Дополнительные параметры системы», перейдите на вкладку «Дополнительно» и нажмите кнопку «Параметры» в разделе «Загрузка и Восстановление». Снимите флажок с параметра «Выполнять автоматическую перезагрузку»:

    [​IMG]

    Если вы работаете на 64-разрядной версии Windows или выше, вам нужно загрузить систему в режиме отладки, чтобы можно было запустить отладчик ядра в режиме «local». Вы можете сделать это либо нажав F8 во время загрузки системы и выбрав режим отладки, либо поставив флажок «Отладка» в утилите «Конфигурация системы» (Msconfig):
    [​IMG]
    Далее перезагрузите систему и запустите отладчик с правами администратора. Настройте отладчик на сервер символов Microsoft, открыв диалоговое окно «Symbol Search Path» из меню Файл и введите следующую строку: srv*c:\symbols*http://msdl.microsoft.com/download/symbols (замените c:\symbols на путь к локальной папке, в которой отладчик должен хранить кэшированные символы). Далее откройте диалоговое окно «Kernel Debugging" из меню Файл, выберите вкладку «Local» и нажмите OK:
    [​IMG]
    Следующие шаги отличаются в зависимости от того, работаете вы с 32-разрядной или 64-разрядной Windows и от версии Windows.


    32-разрядная Windows XP и Windows Server 2003

    Функция, которая отображает BSoD на этих операционных системах, называется KeBugCheck2. Вы ищите место, где функция передает значение цвета функции, которая заливает фон экрана – InbvSolidColorFill. Введите команду «u kebugcheck2», чтобы вывести начало функции, затем вводите команду «u», чтобы пролистать дополнительные страницы кода функции до тех пор, пока вы не увидите ссылку на InbvSolidColorFill (после первого ввода «u», вы можете просто нажать Enter, чтобы повторить команду). Вам нужно будет пропустить 30-40 страниц до того, как вы увидите этот запрос:
    [​IMG]
    Перед этим запросом вы увидите инструкцию «push», использующую в качестве аргумента 4, как показано на рисунке выше. Скопируйте адрес кода этой инструкции, выбрав его из столбца адреса слева и нажав Ctrl+C. Затем в командном окне отладчика введите «eb», затем Ctrl+V, чтобы вставить адрес, затем "+1» и нажмите Enter. Отладчик войдет в режим редактирования памяти, начиная с адреса значения цвета. Теперь вы можете выбрать цвет, который вы хотите. 1 – это красный, 2 – зеленый, вы также можете поэкспериментировать, чтобы получить другой цвет. Просто введите число и нажмите Enter дважды, чтобы подтвердить ввод, после чего выйдите из режима редактирования. Вот как примерно должен выглядеть экран, после того как вы закончите:

    [​IMG]



    64-разрядные версии Windows и 32-разрядные версии Windows Vista или выше​


    На этих версиях Windows функция ядра для отрисовки BSoD называется KiDisplayBlueScreen. Введите «u kidisplaybluescreen» и затем продолжайте вводить команды «u», чтобы пропустит страницы с кодом функции, до тех пор, пока вы не увидите вызов InbvSolidColorFill. На 32-разрядных версиях Windows продолжите следование инструкциям, приведенным в разделе Windows XP/Server 2003, чтобы найти и отредактировать значение цвета. На 64-разрядных версиях этих операционных систем инструкция, предшествующая вызову InvbSolidColorFill, передает цвет, так что скопируйте ее адрес (номер в левой колонке) и введите эту команду для начала редактирования: «eb <address>+4». Отладчик перейдет в режим редактирования памяти, и вы сможете изменить значение (например, 1 для красного, 2 для зеленого):
    [​IMG]


    Просмотр результата

    Теперь вы готовы к сбою системы. Если вы работаете на 64-разрядной Windows, вы можете вызвать сбой без каких-либо дополнительных действий. Kernel Patch Protection заметит модификацию и вызовет сбой системы как средство сдерживания деятельности независимых вендоров, которые могли бы решить подправить код ядра, чтобы изменить его поведение. Однако на это может понадобиться несколько минут. Чтобы вызвать сбой системы по требованию, запустите утилиту Notmyfault (вы можете скачать ее с веб-страницы Windows Internals, посвященной книгам) и нажмите кнопку «Do Bug» (чтобы избежать потери данных, убедитесь, что вы сохранили любую работу и закрыли все другие приложения):
    [​IMG]
    Появится BSoD в цвете, который вы выбрали, в данном случае это «красный экран смерти»:
    [​IMG]
    (с)blogs.technet.com/b/mark_russinovich
     
    Последнее редактирование: 30 дек 2010
    2 пользователям это понравилось.

Поделиться этой страницей