Чтение crash-экранов
Несмотря на ужасающее название "system crash", системный сбой является вполне заурядным событием. Операционная система всего лишь сообщает, что она перешла в такое внутреннее состояние, которое несовместимо с возможностью продолжения работы. Следовательно, полагает операционная система, лучше прекратить работу сейчас, нежели функционировать с этим ошибочным состоянием. И это решение во многих случаях предпочтительнее.
Кто инициирует объявление системного сбоя?
Во-первых, некоторые компоненты уровня ядра, которые "по долгу службы" обнаружили некорректное состояния, могут решить, что пришла пора "сказать стоп". Например, если Диспетчер ввода/вывода обнаруживает, что драйвер передал в вызов IoCompleteRequest
завершенный ранее пакет IRP, то Диспетчер ввода/вывода непременно вызовет этот самый сигнал фатального системного сбоя.
Второй сценарий сложнее. Программный код, работающий в режиме ядра, является непосредственным источником ошибки и генерирует исключение (exception) во время какой-либо операции. Если процедура уровня ядра, которая выполнила эту запрещенную операцию, непосредственно не перехватит это исключение, то результатом будет необрабатываемое исключение режима ядра. Когда это происходит, в работу включается стандартный обработчик исключений в ядре операционной системы, который инициирует системный останов.
Независимо от того, какие подсистемы ядра выступают инициатором системного останова, реально выполняется вызов одной из двух функций:
VOID KeBugCheck( BugChCode ); VOID KeBugCheckEx( BugChCode, Arg1, Arg2, Arg3, Arg4 );
Любая из этих функций вызывает останов системы и (необязательно) сохраняет файл со снимком памяти (crash dump file) на жестком диске. В зависимости от выбора системного администратора, операционная система после этого прекращает работу, перезапускается или запускает отладку ядра (kernel's debug client).
Аргумент BugChCode в вызове KeBugCheck указывает причину сбоя в виде значения типа DWORD. Этот аргумент известен также под именем "bugcheck code". Дополнительные 4 аргумента в функции KeBugCheckEx дают возможность видеть в диагностическом сообщении дополнительную информацию (что, возможно, позволит удачнее локализовать источник сбоя).
Коды "bugcheck codes" могут быть использованы из числа определенных Microsoft (см. файл BUGCODES.h), либо можно определить в драйвере дополнительно.
Драйвер может выполнить вызов любой из этих двух функций. Вообще говоря, общепринятой практикой для отладочных версий драйвера является организация системных STOP-сообщений в критических точках кода.
