Комментарий переводчика. В переводе этой статьи я несколько раз уделил внимание серьезной, на мой взгляд, проблеме – отсутствия строгой русскоязычной терминологии. Поэтому в тексте, в нескольких местах прямо по ходу изложения, Вы натолкнетесь на мои комментарии. Надеюсь, и они дадут Вам почву для размышлений, потому что при расследовании любого отказа оборудования и любого инцидента нельзя допускать двоякого толкования вывода эксперта. В данном случае Вас. Но не буду более отвлекать Вас от нового поста Марка Руссиновича. Пост марка Руссиновича. В предыдущей паре постов я демонстрировал «светлую сторону» «Голубого экрана», показывал, как управлять его цветом. Код ядра Windows улучшается от релиза к релизу и сейчас, уже многие пользователи никогда не видели печально известный BSOD. Но если все же, Вам доводилось его видеть (имеется ввиду, не используя специально Notmyfault) в таком виде, каком я его описываю в моей презентации «Дело о необъясненном», то потратьте несколько минут на ее изучение, а в дальнейшем эти минуты могут уберечь Вас от нервов и возможной потери данных, когда Вы столкнетесь с описанными отказами системы. Этот пост я начну с основ анализа «крэш дампа» (аварийного дампа – для тех, кто не знает, «дампом памяти» называется сохраненное в файле состояние оперативной памяти на какой-то момент работы системы, в данном случае – на момент аварии – примечание ArkSmoke’а). В большинстве случаев достаточно даже простого анализа, чтобы найти бажный драйвер и скачать его свежую версию из сети, но иногда анализ бывает очень двусмысленный. Я поделюсь двумя примерами, которые мне прислали администраторы, где правильно составленный запрос в сети позволил решить все возникшие проблемы. Разбор аварии (расследование инцидента, дебаг падения – кому как нравится. Хотя, лично я считаю, что надо разработать однозначную русскоязычную терминологию или пользоваться англоязычными терминами, но не в коем случае, не допускать использования одного термина для определения разных состояний или явлений, что сплошь и рядом мы наблюдаем сейчас. Я всячески стараюсь приводить все известные мне термины, но факт, что я владею всей терминологией данного процесса, так что будьте очень внимательны к использованию термина – замечание ArkSmoke’а) начинается того, что надо скачать Пакет Инструментов Отладки Windows (Debugging Tools for Windows package), это часть Windows SDK. Обратите внимание, что Вы можете скачать и установить только Отладочные Инструменты (Debugging Tools), и не качать целиком SDK. Затем надо установить этот пакет, а после - сконфигурировать, указав Microsoft symbol сервис, чтобы отладчик сумел скачать символы ядра, которые будут необходимы при интерпретации аварийного дампа. Это можно сделать, открыв «диалог конфигурации символов», располагающийся ниже меню «Файл», и введя в него URL адрес Microsoft symbol сервера с именем папки, в которую система будет размещать КЭШи символов файлов загрузки: Следующий шаг: загрузите аварийный дамп в отладчик, для этого нажмите Open Crash Dump в меню «Файл». Будет зависеть от Вашей версии Winwows, где система сохраняет файлы дампов; так же имеет различие клиентскую или серверную систему Вы используете. Вот простой метод нахождения файлов дампа в системе: сначала проверьте файл с именем Memory.dmp в папке %SystemRoot% (обычно это C:\Windows), если такого файла Вы не нашли, проверьте папку %SystemRoot%\Minidumps и загрузите самый свежий файл minidump (предполагается, что Вам нужно работать с последним падением системы). Когда Вы загрузите файл дампа в отладчик, дебагер (опять же разные термины одного программного комплекса - ArkSmoke), используя эвристические алгоритмы, попытается определить причину краха. Он укажет на наиболее вероятный драйвер, напечатав «Probably caused by:», а дальше имя драйвера, компонента Windows, или проблему с оборудованием – то, из-за чего, по мнению отладчика, произошел инцидент (в нашем случае – падение системы): Обратите так же внимание на !analyze –v – гиперссылку, которая отобразит более подробную информацию, включающую сведения о стеке потока ядра, который выполнялся, когда система рухнула. Эта гиперссылка часто используется, когда эвристические алгоритмы не в силах определить причину падения системы, такое получается, когда во время аварии активны драйвера сторонних разработчиков, но они могут иметь к краху лишь косвенное отношение. Установка новых версий драйверов сторонних разработчиков, которые отображаются при простом анализе, часто приводят к исправлению ситуации. Я показываю поиск решения в этой ситуации в своем посте – «The Case of the Crashed Phone Call». Когда Вы не находите никакого решения, используя эвристические алгоритмы отладчика, выполните поиск в сети полного текстового описания кода проблемы (выполните !analyze –v команду) и еще ключевое слово, которое описывает оборудование или программное обеспечение, по вине которого могло произойти падение системы. Например, одни администратор насобирал аварийных дампов с нескольких серверов, обслуживающих фермы. И никак не мог понять, что с ними делать, до тех пор, пока не увидел презентацию «Дела о необъясненном». После возращения с конференции он открыл дампы с нескольких «проблемных» систем. Анализ дампов выявил одно общие решение в каждом случае, драйвер не использовал связную память ядра при сессии удаленного пользователя, когда это предполагалось: Надеясь, что поиск в сети может натолкнуть его на решение, и точно ничего не теряя, он ввел в строку поиска браузера «session_has_valid_pool_on_exit and citrix». К его изумлению, первым результатом была Citrix Knowledge Base – база, в которой была заплатка как раз для той проблемы, которую он пытался решить, и даже статьи отображались с тем же текстовым полем отладчика, что и у него: После скачивания и установки этой заплатки, сервер фермеров стал отказоустойчивым. В другом случае администратор наблюдал падение сервера три раза за несколько дней. К несчастью, анализ не дал решения проблемы. Казалось, осталось сказать, что система падала из-за того, что таймеры контроля исчерпывали лимиты: Как и в предыдущем случае, администратор ввел параметры строк аварийного дампа в поисковую машину, и первая заметка анонсировала решение его проблемы: И после применения предложенных исправлений сервер больше не падал. Эти случаи показывают, что устранение неисправностей с родни поиску улик, которые приводят Вас к решению проблемы или заставляют идти в обход, но те ключи, которые очевидны, требуют мало работы и творчества. В конечном итоге, не важно, как и где Вы найдете подсказки, главное – как долго Вы будите решать проблему.
