Проблема приоритетов времени выполнения
Как мог заметить читатель, описание всех системных вызовов в данной книге (кроме того — и в документации DDK) приводятся с обязательным указанием, на каком уровне IRQL (приоритетов уровня ядра) может работать программный код в момент обращения к ним. Поскольку приоритет вызывающего кода по умолчанию переходит на вызываемые процедуры (которые, возможно, не должны никогда работать на этом уровне), то операционная система тщательно отслеживает, чтобы уровень приоритета, который "передался" ее компонентам, соответствовал бы установленным правилам. Наиболее часто жертвой столь ревностного соблюдения правил становится высокоприоритетный код, обращающийся к страничной памяти, которая оказалась сброшенной на диск. Система не позволяет вступать в работу своим функциям, чтобы обслужить данное затруднение, поскольку отступление от данного правила считается вредным для системы.
Разработчик драйвера должен всегда следить за приоритетом текущего программного кода и документированным уровнем IRQL вызываемых системных функций. В противном случае возможен (а иногда — просто неминуем) крах операционной системы, а ответ придется искать уже в crach dump файле.
Показательным случаем неправильного использования приоритетов является вызов другого драйвера при помощи IoCallDriver, который формально может быть выполнен на уровнях IRQL APC_LEVEL и DISPATCH_LEVEL. Повысив текущий приоритет потока перед вызовом IoCallDriver до значения, например, DISPATCH_LEVEL, драйвер, скорее всего, организует блокировку: если вызываемый драйвер должен работать на уровне PASSIVE_LEVEL, то он не может сделать нужные ему вызовы, пока работает вызвавший его поток, который ждет возвращения управления из IoCallDriver. Система приходит в неработоспособное состояние ("замерзает").
