Как изменить bsod

Настраиваем пользовательский синий экран смерти

Он посинел, ему плохо?

BSOD – реакция ядра на неразрешимую исключительную ситуацию. Если вы его видите, то это значит, что случилось что-то определенно нехорошее.

Среда ядра накладывает множество ограничений на свободу действий программиста: учитывай IRQL, синхронизируй доступ к разделяемым переменным, не задерживайся в ISR, проверяй любые данные из «юзерленда»… Нарушив хотя бы одно из правил, вы получите настоящий выговор из штампованных фраз в стандартном VGA-видеорежиме с худой палитрой.

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

В кернелмоде все иначе. Во-первых, кернелмодные соседи – уже соседи не по квартире, но по комнате. Между ними нет прочных стен, которые бы защитили одних жильцов от нетрезвых выходок других. При этом взаимосвязи кернелмодных модулей тонки и хрупки. Ядро и его компоненты – гигантские часы, с огромным количеством компонентов. И в этом соль: если один винтик поврежден, останавливается вся система. Конечно, есть модули, сбои которых логически никак не влияют на работу ОС. Можно было бы изолировать сбойный модуль – кое-где так делают, ну, вы знаете. Однако логика заключается в том, что ядерный компонент активно взаимодействует с другими компонентами и ядром ОС, следовательно, сбой в одном компоненте может привести к цепочке сбоев в других, в конечном счете разрушив все ядерные структуры, или, что еще хуже, повредить пользовательские данные. Кроме того, отлаживать такие затаившиеся баги крайне тяжело.

Тем не менее, допустим, вы – пользователь уровня «чайник». Какая вероятная реакция будет у вас при виде синего экрана?

Допустим теперь, что вы – системный администратор. Какая у вас реакция на «синяк»? Ну, до того, как вы начинаете читать код ошибки и все такое.

Пусть вы кернелкодер, и вам кучу раз приходилось видеть этот изощренный отладочный вывод. Что вам приходит в голову, когда вы видите его снова? Ну, кроме междометий.

А имеем за сим, с одной стороны, невозможность продолжить нормальное функционирование системы, с другой, – бесценные невосстанавливающиеся нервные клетки. Как быть? Перехват KeBugCheck не предлагать – мы все знаем, что из этого выйдет. До релиза Windows 8 с ее душевным DirectX BSOD’ом нужно еще подождать какое-то время. А пока что…

Сам себе Руссинович

Думаю, всем знакомо это имя. Руссинович классный, хоть и хитрит. Среди кучи полезных утилит от Sysinternals есть одна интересная – NotMyFault. Она может искусственно генерировать различные ошибки в режиме ядра, что, конечно же, отобразит BSOD. Кроме того, в ней есть интересная возможность – изменить цвет фона и шрифта экрана смерти. Эта утилита настолько крута, что даже поставляется вместе с исходником! Однако, как я уже говорил, Руссинович классный…

Я какое-то время не мог понять, что происходит: в заголовочном файле ioctlcmd.h есть такой код:

#define IOCTL_BSOD_COLOR (ULONG) CTL_CODE(FILE_DEVICE_MYFAULT, 0x10, METHOD_BUFFERED, FILE_ANY_ACCESS)

Но это единственное место, где есть след кода, отвечающего за изменение цвета экрана смерти. Файл драйвера myfault.c содержит в себе кулинарную книгу ядерных извращений без главного блюда! Но! Собранный драйвер, по-видимому, нужный код все-таки имеет, поскольку отрабатывает на ура. «Окей», – подумал я.

Отвлечемся на минутку. Прежде, чем вы задумаете что-то сплайсить в ядре, не поленитесь заглянуть на MDSN, поскольку callback-функций (функций обратного вызова) в ядре предостаточно. Так и с синим экраном: есть callback-функция, вызов которой происходит сразу после отображения синего экрана. Регистрируется она следующей функцией:

BOOLEAN KeRegisterBugCheckReasonCallback(
 __out PKBUGCHECK_REASON_CALLBACK_RECORD CallbackRecord,
 __in  PKBUGCHECK_REASON_CALLBACK_ROUTINE CallbackRoutine,
 __in  KBUGCHECK_CALLBACK_REASON Reason,
 __in  PUCHAR Component
);

Эта callback-функция указывает причину своей регистрации: либо ей необходимо дописать что-то в дамп, либо отследить момент, когда дамп уже записан, либо, указав в качестве причины KbCallbackReserved1, мы можем быть вызваны «просто так». Параметр KbCallbackReserved1 является приватным и вызывается раньше всех остальных callback-функций при возникновении критических ошибок.

Кроме этой callback-функции есть и другая, похожая, которая регистрируется следующей функцией:

BOOLEAN KeRegisterBugCheckCallback(
 __out   PKBUGCHECK_CALLBACK_RECORD CallbackRecord,
 __in   PKBUGCHECK_CALLBACK_ROUTINE CallbackRoutine,
 __in_opt PVOID Buffer,
 __in   ULONG Length,
 __in   PUCHAR Component
);

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

Снова к делу. Увидев в дизассемблерном листинге автоматически назначенное имя функции «CallbackRoutine», я даже и не знал, куда еще можно отправиться в поисках волшебного кода. И вот же он! … Стойте, что это? «Mov – out, mov – out». Не знаю, как у вас, а у меня было такое чувство, что меня обманули. Я ждал чудес и сказки. А тут Марк берет VGA-порты и через них меняет палитру. Именно палитру! Т. е. делает синий цвет, например, зеленым, так что фон окрашивается в зеленый цвет:

mov edx, 3C8h    ; порт, в который записывается индекс цвета в палитре ЦАП
mov al, 4           ; был синий
out dx, al
mov al, 0x00003F00   ; станет зеленый (6 бит на цвет)
lea ecx, [edx+1]       ; edx = 0x3C9 – порт для записи цветовых компонент
mov edx, ecx
out dx, al          ; установить Red-составляющую
mov eax, 0x00003F00
shr eax, 8
out dx, al          ; Green
mov eax, 0x00003F00
shr eax, 10h
out dx, al          ; Blue

Ну что ж, в принципе тоже сойдет. Но хочется большего.

Наслаждайтесь мелочами

Анимированный экран загрузки ОС, в принципе, дает хорошее представление о том, что можно выжать из VGA-видеорежима. Можно даже догадаться о том, что код для отрисовки графики уже есть готовый где-то в ядре. Не буду томить: нас интересует семейство функций Inbv*. Обратите внимание на то, что некоторые из них даже являются экспортируемыми из ядра. На примере реверса KiDisplayBlueScreen можно разобраться, как пользоваться такими функциями:

if (InbvIsBootDriverInstalled())
{
  InbvAcquireDisplayOwnership();          // теперь мы командуем
  InbvResetDisplay();                          // очищаем экран, переинициализируем палитру
  InbvSolidColorFill(0, 0, 639, 479, 4);    // заливаем все синей краской
  InbvSetTextColor(15);                      // а пишем белой
  InbvInstallDisplayStringFilter(0);         // сбрасываем callback-функцию на отображение текстовой строки
  InbvEnableDisplayString(TRUE);          // разрешаем писать строки
  InbvSetScrollRegion(0, 0, 639, 475);   // сужаем рамки экрана
  …
  InbvDisplayString(«Hello world!»);       // выводим текст
  …
};

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

Но самая примечательная функция – InbvBitBlt:

VOID NTAPI InbvBitBlt(IN PUCHAR Buffer, IN ULONG X, IN ULONG Y)

Догадываетесь? Да, она непосредственно отрисовывает BMP-изображение (читай, BMP-файл с 256 цветами без файлового заголовка)! Проблема только в том, что она неэкспортируемая. К счастью, она – всего лишь обертка аналогичной функции VidBitBlt. Роль обертки заключается только в синхронизации отрисовки, что, в общем-то, нас не сильно интересует. А VidBitBlt экспортируется из модуля bootvid.dll, который, как можно догадаться по названию, развлекает пользователя загрузочной анимацией. Так что в путь, мои дорогие! Абсолютно легально ищем загруженные модули, парсим таблицу экспорта и получаем указатель на эту волшебную функцию. А дальше вы ограничены только своей фантазией.

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

Всем позитива!

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

Поскольку нам придется изменить код ядра, первый шаг заключается в разрешении редактировать код ядра в памяти, если это ранее не было сделано. Системы Windows с менее чем 2 Гб ОЗУ используют страницы объемом 4 Кб для хранения кода ядра, благодаря чему можно обеспечить необходимый уровень защиты для содержимого. Например, страницы данных ядра должны разрешать доступ на чтение и запись, в то время как код ядра должен предоставлять доступ только для чтения и выполнения.

В рамках оптимизации, которая позволяет увеличить скорость трансляции виртуальных адресов, Windows использует большие страницы (4 Мб на x86 и x64) на больших системах. Это означает, что если в странице хранится и код, и данные, то эта страница должна представлять доступ на чтение, запись и выполнение; так что для того, чтобы гарантировать возможность редактирования страницы, вы должны обеспечить использование Windows больших страниц.

Если у вас Windows XP или Windows Server 2003 и менее 256 Мб ОЗУ, или Windows Vista или старше и есть 2 Гб ОЗУ или меньше, создайте значение REG_DWORD с названием LargePageMinimum, которое установлено в 1, в ветке реестра HKLMSystemCurrentControlSetControlSession ManagerMemory Management:

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

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

Если вы работаете на 64-разрядной версии Windows Vista или выше, вам нужно загрузить систему в режиме отладки, чтобы можно было запустить отладчик ядра в режиме «local». Вы можете сделать это либо нажав F8 во время загрузки системы и выбрав режим отладки, либо поставив флажок «Отладка» в утилите «Конфигурация системы» (Msconfig):

Далее перезагрузите систему и запустите отладчик с правами администратора. Настройте отладчик на сервер символов Microsoft, открыв диалоговое окно «Symbol Search Path» из меню Файл и введите следующую строку: srv*c:symbols*http://msdl.microsoft.com/download/symbols (замените c:symbols на путь к локальной папке, в которой отладчик должен хранить кэшированные символы). Далее откройте диалоговое окно «Kernel Debugging» из меню Файл, выберите вкладку «Local» и нажмите OK:

Следующие шаги отличаются в зависимости от того, работаете вы с 32-разрядной или 64-разрядной Windows и от версии Windows.

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

Функция, которая отображает BSoD на этих операционных системах, называется KeBugCheck2. Вы ищите место, где функция передает значение цвета функции, которая заливает фон экрана – InbvSolidColorFill. Введите команду «u kebugcheck2», чтобы вывести начало функции, затем вводите команду «u», чтобы пролистать дополнительные страницы кода функции до тех пор, пока вы не увидите ссылку на InbvSolidColorFill (после первого ввода «u», вы можете просто нажать Enter, чтобы повторить команду). Вам нужно будет пропустить 30-40 страниц до того, как вы увидите этот запрос:

Перед этим запросом вы увидите инструкцию «push», использующую в качестве аргумента 4, как показано на рисунке выше. Скопируйте адрес кода этой инструкции, выбрав его из столбца адреса слева и нажав Ctrl+C. Затем в командном окне отладчика введите «eb», затем Ctrl+V, чтобы вставить адрес, затем «+1» и нажмите Enter. Отладчик войдет в режим редактирования памяти, начиная с адреса значения цвета. Теперь вы можете выбрать цвет, который вы хотите. 1 – это красный, 2 – зеленый, вы также можете поэкспериментировать, чтобы получить другой цвет. Просто введите число и нажмите Enter дважды, чтобы подтвердить ввод, после чего выйдите из режима редактирования. Вот как примерно должен выглядеть экран, после того как вы закончите:

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 для зеленого):

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

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

Чтобы вызвать сбой системы по требованию, запустите утилиту Notmyfault (вы можете скачать ее с веб-страницы Windows Internals) и нажмите кнопку «Do Bug» (чтобы избежать потери данных, убедитесь, что вы сохранили любую работу и закрыли все другие приложения):

Появится BSoD в цвете, который вы выбрали, в данном случае это «красный экран смерти»:

Праздничный BSoD

В духе наступающих праздников, я сделал еще один шаг и создал праздничный BSoD: я поменял не только цвет фона, но и цвет текста. Чтобы сделать это на 64-разрядных версиях Windows Vista или выше, найдите вызов InvbSetTextColor сразу после InvbSolidColorFill и адрес инструкции, которая передает цвет текста функции, «move ecx, 0Fh»:

Параметр 0Fh означает белый цвет, но вы можете изменить его, используя все ту же методику редактирования. Используйте команду «eb», передавая адрес инструкции плюс 1. Ниже я установил красный цвет (который имеет значение 1):

А вот и праздничный BSoD, который я создал:

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

Автор: эксперт исследовательского центра Positive Research Артем Шишкин

Он посинел, ему плохо?

 BSOD – реакция ядра на неразрешимую исключительную ситуацию. Если вы его видите, то это значит, что случилось что-то определенно нехорошее.

 Среда ядра накладывает множество ограничений на свободу действий программиста: учитывай IRQL, синхронизируй доступ к разделяемым переменным, не задерживайся в ISR, проверяй любые данные из «юзерленда»… Нарушив хотя бы одно из правил, вы получите настоящий выговор из штампованных фраз в стандартном VGA-видеорежиме с худой палитрой.

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

 В кернелмоде все иначе. Во-первых, кернелмодные соседи – уже соседи не по квартире, но по комнате. Между ними нет прочных стен, которые бы защитили одних жильцов от нетрезвых выходок других. При этом взаимосвязи кернелмодных модулей тонки и хрупки. Ядро и его компоненты – гигантские часы, с огромным количеством компонентов. И в этом соль: если один винтик поврежден, останавливается вся система. Конечно, есть модули, сбои которых логически никак не влияют на работу ОС. Можно было бы изолировать сбойный модуль – кое-где так делают, ну, вы знаете. Однако логика заключается в том, что ядерный компонент активно взаимодействует с другими компонентами и ядром ОС, следовательно, сбой в одном компоненте может привести к цепочке сбоев в других, в конечном счете разрушив все ядерные структуры, или, что еще хуже, повредить пользовательские данные. Кроме того, отлаживать такие затаившиеся баги крайне тяжело.

 Тем не менее, допустим, вы – пользователь уровня «чайник». Какая вероятная реакция будет у вас при виде синего экрана?

 Допустим теперь, что вы – системный администратор. Какая у вас реакция на «синяк»? Ну, до того, как вы начинаете читать код ошибки и все такое.

 Пусть вы кернелкодер, и вам кучу раз приходилось видеть этот изощренный отладочный вывод. Что вам приходит в голову, когда вы видите его снова? Ну, кроме междометий.

 А имеем за сим, с одной стороны, невозможность продолжить нормальное функционирование системы, с другой, – бесценные невосстанавливающиеся нервные клетки. Как быть? Перехват KeBugCheck не предлагать – мы все знаем, что из этого выйдет. До релиза Windows 8 с ее душевным DirectX BSOD’ом нужно еще подождать какое-то время. А пока что…

Сам себе Руссинович

 Думаю, всем знакомо это имя. Руссинович классный, хоть и хитрит. Среди кучи полезных утилит от Sysinternals есть одна интересная – NotMyFault. Она может искусственно генерировать различные ошибки в режиме ядра, что, конечно же, отобразит BSOD. Кроме того, в ней есть интересная возможность – изменить цвет фона и шрифта экрана смерти. Эта утилита настолько крута, что даже поставляется вместе с исходником! Однако, как я уже говорил, Руссинович классный…

 Я какое-то время не мог понять, что происходит: в заголовочном файле ioctlcmd.h есть такой код:

#define IOCTL_BSOD_COLOR (ULONG) CTL_CODE(FILE_DEVICE_MYFAULT, 0x10,

METHOD_BUFFERED, FILE_ANY_ACCESS)

Но это единственное место, где есть след кода, отвечающего за изменение цвета экрана смерти. Файл драйвера myfault.c содержит в себе кулинарную книгу ядерных извращений без главного блюда! Но! Собранный драйвер, по-видимому, нужный код все-таки имеет, поскольку отрабатывает на ура. «Окей», – подумал я.

 Отвлечемся на минутку. Прежде, чем вы задумаете что-то сплайсить в ядре, не поленитесь заглянуть на MDSN, поскольку callback-фукнций (функций обратного вызова) в ядре предостаточно. Так и с синим экраном: есть callback-функция, вызов которой происходит сразу после отображения синего экрана. Регистрируется она следующей функцией:

  BOOLEAN KeRegisterBugCheckReasonCallback(  

 __out PKBUGCHECK_REASON_CALLBACK_RECORD CallbackRecord,  

 __in PKBUGCHECK_REASON_CALLBACK_ROUTINE CallbackRoutine,  

 __in KBUGCHECK_CALLBACK_REASON Reason,  

 __in PUCHAR Component  

 );

Эта callback-функция указывает причину своей регистрации: либо ей необходимо дописать что-то в дамп, либо отследить момент, когда дамп уже записан, либо, указав в качестве причины KbCallbackReserved1, мы можем быть вызваны «просто так». Параметр KbCallbackReserved1 является приватным и вызывается раньше всех остальных callback-функций при возникновении критических ошибок.

 Кроме этой callback-функции есть и другая, похожая, которая регистрируется следующей функцией:

BOOLEAN KeRegisterBugCheckCallback(  

 __out PKBUGCHECK_CALLBACK_RECORD CallbackRecord,  

 __in PKBUGCHECK_CALLBACK_ROUTINE CallbackRoutine,  

 __in_opt PVOID Buffer,  

 __in ULONG Length,  

 __in PUCHAR Component  

 );

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

 Снова к делу. Увидев в дизассемблерном листинге автоматически назначенное имя функции «CallbackRoutine», я даже и не знал, куда еще можно отправиться в поисках волшебного кода. И вот же он! … Стойте, что это? «Mov – out, mov – out». Не знаю, как у вас, а у меня было такое чувство, что меня обманули. Я ждал чудес и сказки. А тут Марк берет VGA-порты и через них меняет палитру. Именно палитру! Т. е. делает синий цвет, например, зеленым, так что фон окрашивается в зеленый цвет:  

mov edx, 3C8h ; порт, в который записывается индекс цвета в палитре ЦАП  

 mov al, 4 ; был синий  

 out dx, al  

 mov al, 0x00003F00 ; станет зеленый (6 бит на цвет)  

 lea ecx, [edx+1] ; edx = 0x3C9 – порт для записи цветовых компонент  

 mov edx, ecx  

 out dx, al ; установить Red-составляющую  

 mov eax, 0x00003F00  

 shr eax, 8  

 out dx, al ; Green  

 mov eax, 0x00003F00  

 shr eax, 10h  

 out dx, al ; Blue

 Ну что ж, в принципе тоже сойдет. Но хочется большего.

Наслаждайтесь мелочами

 Анимированный экран загрузки ОС, в принципе, дает хорошее представление о том, что можно выжать из VGA-видеорежима. Можно даже догадаться о том, что код для отрисовки графики уже есть готовый где-то в ядре. Не буду томить: нас интересует семейство функций Inbv*. Обратите внимание на то, что некоторые из них даже являются экспортируемыми из ядра. На примере реверса KiDisplayBlueScreen можно разобраться, как пользоваться такими функциями:

if (InbvIsBootDriverInstalled())  

 {  

 InbvAcquireDisplayOwnership(); // теперь мы командуем  

 InbvResetDisplay(); // очищаем экран, переинициализируем палитру  

 InbvSolidColorFill(0, 0, 639, 479, 4); // заливаем все синей краской  

 InbvSetTextColor(15); // а пишем белой  

 InbvInstallDisplayStringFilter(0); // сбрасываем callback-функцию на отображение текстовой строки  

 InbvEnableDisplayString(TRUE); // разрешаем писать строки  

 InbvSetScrollRegion(0, 0, 639, 475); // сужаем рамки экрана  

 …  

 InbvDisplayString(«Hello world!»); // выводим текст  

 …  

 };

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

 Но самая примечательная функция – InbvBitBlt:

VOID NTAPI InbvBitBlt(IN PUCHAR Buffer, IN ULONG X, IN ULONG Y)

Догадываетесь? Да, она непосредственно отрисовывает BMP-изображение (читай, BMP-файл с 256 цветами без файлового заголовка)! Проблема только в том, что она неэкспортируемая. К счастью, она – всего лишь обертка аналогичной функции VidBitBlt. Роль обертки заключается только в синхронизации отрисовки, что, в общем-то, нас не сильно интересует. А VidBitBlt экспортируется из модуля bootvid.dll, который, как можно догадаться по названию, развлекает пользователя загрузочной анимацией. Так что в путь, мои дорогие! Абсолютно легально ищем загруженные модули, парсим таблицу экспорта и получаем указатель на эту волшебную функцию. А дальше вы ограничены только своей фантазией.

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

 Всем позитива!

Теперь пользователи могут просто запустить Notmyfault и выбрать новый цвет в представленной палитре оттенков, сгенерировав нудный цвет BSOD. Для этого достаточно запустить программу и выбрать кнопку Do Bug. В открывшемся окошке достаточно поколдовать с палитрой, нажать ОК – и – вуаля! – экран из синего стал голубым! Ну, или таким, как вашей душе угодно.

Сам Руссинович объясняет: «Мы расширили драйвер режима ядра инструмента Notmyfault (он называется Myfault.sys, как видно на рисунке выше, чтобы подчеркнуть тот факт, что в пользовательском режиме код не может непосредственно привести к краху системы), чтобы регистрировать «обратный вызов отладки. Когда система падает, он вызывает зарегистрированный драйвером обратный вызов, так данные о состоянии самого устройства или драйвера добавляются в аварийный дамп, помогая устранить неполадки на момент аварии. Обратный вызов Myfault.sys выполняется сразу после появления экрана, сообщающего об ошибке, и одновременно изменяет цвет согласно информации, переданной Notmyfault».

Вот так в общих чертах происходит этот процесс. В результате вы получаете веселенький BSOD и удивляете им свою доверчивую девушку, говоря, что сделали это собственными руками. Кстати говоря, новая книга Руссиновича, Ионеску и Дейва Соломона, посвященная Windows 7 и Windows Server 2008 R2, выйдет летом 2011 года. И говорят, что это будет настоящий кибер-триллер.