Анализ проблем верификации драйверов Windows
7
Рис. 4.
Моделирование повторного захвата спин-блокировки
В первом случае при отключенном режиме Driver Verifier систе-
ма самостоятельно вызвала крах, но определить источник ошибки не
смогла. Анализ аварийного дампа также не позволил определить
драйвер, виновный в крахе системы, а в уцелевшем стеке ядра экспе-
риментальный драйвер вообще не фигурировал. Фрагмент дампа па-
мяти с пятью последними элементами стека показан на рис. 5. В дам-
пе указано, что ошибку вызвал процесс ntoskrnl.exe (исполнительная
система и ядро для однопроцессорных систем).
В случае вызова функции SpinLock() анализировать крах систе-
мы очень сложно, потому что он происходит в момент обращения к
поврежденным данным, а не входа в блокировку. Так как система
некоторое время продолжает работать после ошибки чтения стра-
ницы, анализ аварийного дампа может указать на другой процесс,
функции которого исполнялись непосредственно в момент краха.
В данном случае последними были вызваны драйвер hal и процесс
ntoskrnl.exe.
Во втором случае режим анализа взаимоблокировок в Driver Veri-
fier был включен. После генерации краха системы, инициированного
программой Driver Verifier, удалось установить драйвер, явившийся
причиной краха. Однако локализация ошибки не выполнена. При
анализе (рис. 6) легко определить, что ошибка организована двумя
файлами — halmacpi.dll и Primer.sys.
Вызов экспериментального драйвера в стеке находится очень
«глубоко», но поскольку после произошедшей ошибки вызывались
только системные драйвера типа hal и nt, вероятно, виновник краха —
экспериментальный драйвер.
