С этим неприятным явлением наверняка сталкивался каждый более или менее опытный пользователь MS Windows. А системные администраторы и подавно, для них это явный признак того, что либо (а) последние изменения в системе (установленные драйверы или программы, измененные настройки) явно не пошли ОС на пользу, либо (б) в скором будущем ОС придется переустановить. В последнее время, из-за повсеместного общественного неприятия Windows Vista, от этого страдают большинство пользователей современных ноутбуков, предназначенных для работы под Vista, но волею судеб корчащиеся под XP. Большинство "членов клуба" относится к BSoD как к неизбежному злу, и мало кто пробовал разобраться, каковы его истинные причины, что за теоретические аспекты за ним скрываются и какую... пользу можно из него извлечь.
Немного теории. Есть такое понятие, как безопасное состояние системы. Это когда отношения между субъектом (пользователь, клиентское ПО, драйвер) и объектом (сервис, системный вызов, прерывание) регламентируются определенной политикой безопасности. Допустим, существует некое количество безопасных состояний и некое количество транзитных функций, переводящих систему из одного состояния в следующее (примеры транзитных функций: ввод текста пользователем, начало итерации цикла, получение и обработка сетевой датаграммы). Это так называемая машина состояний, которая основывается на математическом выводе: если стартовое состояние системы - безопасное, а все выполняемые над системой транзитные функции - тоже безопасны, то и каждое последующее состояние системы будет безопасным (вспоминаете метод математической индукции?)
Естественно, немногие системы настолько "замкнуты" и защищены, что категорически не позволяют добавлять в себя новые функции. Эти новые функции (ПО, драйверы и т.п.) крайне редко безопасны настолько, насколько хотелось бы создателям системы. Поэтому создатели предусматривают проверку соблюдения политики безопасности системы перед каждой сменой состояния. В случае, когда транзитная функция пытается перевести систему в небезопасное состояние угрожающее целостности системы, последней не остается ничего лучше, чем вернуться к изначальному состоянию - то есть перезагрузиться. Blue Screen Of Death как раз для этого и предназначен: сохранив на диск (для возможного последующего расследования) доказательства целесообразности своих действий, он блокирует подозрительную транзитную функцию и перезагружает операционку.
Здесь можно выбрать тип дампа. Лучше выбрать полный, но не забудьте периодически удалять его из соответствующей директории или поставьте галочку "Заменять существующий файл дампа". Для того, чтобы произвольно вызвать BSoD, присвойте ключу HKLMSYSTEMCurrentControlSetServicesi8042prtParametersCrashOnCtrlScroll (REG_DWORD) значение 1 (изменения вступят в силу после перезагрузки). После этого удерживая правый Ctrl дважды нажмите Scroll Lock и вуаля! До встречи после ребута!
Давайте теперь проанализируем файл дампа ОЗУ. Поверьте, там можно найти очень много интересного. Подробный анализ лучше проводить специальными средствами: бинарным редактором и/или дизассемблером. Начать можно с поиска "читабельных" строк при помощи утилиты strings в составе Sysinternals Suite .
В результате получится очень большой ТХТ-файл, не советую пробовать открывать его обычным Блокнотом. Вместо этого используйте Notepad++ . Поковыряйтесь в нем пол часика, будете удивлены как много любопытных вещей хранятся в ОЗУ в текстовом виде.
Кстати, цвета отображения сообщения о критической ошибке можно изменять. Практического смысла нет, но в качестве шутки над начинающим админом - то что надо. За цвета отвечают два параметра в файле C:WINDOWSsystem.ini в секции [386enh]
MessageBackColor=9
MessageTextColor=F
Если таких строк нет, их придется создать. Коды цветов следующие: 0 = черный, 1 = синий, 2 = зеленый, 3 = голубой, 4 = красный, 5 = пурпурный, 6 = желто-коричневый, 7 = белый, 8 = серый, 9 = ярко-синий, A = ярко-зеленый, B = яркий бирюзовый, C = ярко-красный, D = ярко пурпурного, E = ярко-желтый, F = ярко-белый.
