Linux и Windows: помощь админам и пользователям

Администрируем и настраиваем Windows, Linux.

bsod

За прошлые несколько месяцев я проводил интервью у нескольких кандидатов на должность системного администратора, и один из вопросов, которые я задавал - какие шаги вы предпринимаете в поиске неисправностей в случае "синего экрана смерти". Я пытался узнать, какой подход человек проявляет когда столкивается с страшным "синим" экраном, и ответы, которые я получил, очень удивили меня, и не всегда приятно. У многих из кандидатов не было методического подхода, и чаще чем мне бы хотелось, первые шаги, которые по их словам они бы сделали заключались бы в переустановке или перезаливке операционной системы, или замене памяти. Не понимайте меня превратно, переустанавка ОС или замена памяти могут решить некоторые вызывающие "синий" экран проблемы, но они не должны быть первыми сделанными шагами поиска неисправностей.

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

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

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

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

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

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

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

Хотя это сообщеине выглядит довольно спартанским, здесь все ещё есть немного полезной информации – раздел “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 219.

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

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

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

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

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

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

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

Автор: Ben Lye. Оригинал на английском находится на сайте simple-talk.com

 

 

Полезные ссылки:

Недавно потребовалось составлять различные договора, в том числе трудовой договор. Скажу честно, не ожидал что это будет такой сложной задачей. Если бы я не нашел программу QuickDoc Конструктор договоров, пришлось бы потратить уйму времени вникая во все эти юридические тонкости.