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

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

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

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

Рисунок 1 - пример довольно распространенного сообщения – "DRIVER_IRQL_NOT_LESS_OR_EQUAL”. 

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

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

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

Шаг 2 – Поиск

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

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

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

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

Шаг 3 – Анализ

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

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

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

Дамп Памяти ядра

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

Малый Дамп Памяти

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

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

     После установки WinDbg должен быть сконфигурирован, чтобы использовать Microsoft Symbol Server. Как только символы сконфигурированы, щелкните по меню File, выберите Open Crash Dump, и укажите файл дампа отказа, который Вы хотите проанализировать. Вывод от WinDbg будет похож на это:

     Вторая с конца сторока, которая начинается со слов "Probably caused by” указывает, что отладчик предполагает причиной отказа. В примере в рисунке 5 отладчик нашел проблему правильно - этот отказ был вызван NotMyFault. Другая информация в анализе указывает, что файл дампа отказа - дамп памяти ядра, и что файлы символа не могли быть загружены для myfault.sys (потому что это - сторонний драйвер, и символы не доступны на Microsoft Symbol Server).

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

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

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

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