Н.Г. Ершов
,
Н.Ю. Рязанова
10
не может быть захвачен рекурсивно, а поток, захвативший быстрый
мьютекс, не может получать некоторые APC, что ограничивает воз-
можность обмена сообщениями через синхронные IRP. ExAcquire
Fast Mutex Unsafe ставит поток в состояние ожидания на мьютексе,
если указанный быстрый мьютекс не может быть получен немедлен-
но. В противном случае вызывающему потоку дается право соб-
ственности на мьютекс и эксклюзивный защищенный доступ к ре-
сурсу. Далее происходит освобождение мьютекса 1 и повторный
ошибочный захват мьютекса 2. Возникает тупик.
Были проведены эксперименты с включенным режимом отсле-
живания взаимоблокировок Driver Verifier и без него. По умолчанию
(при отключенном режиме выявления взаимоблокировок) в операци-
онной системе нет штатных средств обработки такого вида тупиков,
поэтому при вызове функции Deadlock() система зависает, не органи-
зуя при этом крах. Единственным способом ликвидации такого тупи-
ка является перезагрузка. Естественно, никакого аварийного дампа
при этом не создается, и определить причину зависания невозможно.
При включенном режиме выявления взаимоблокировок Driver
Verifier определяет проблемный драйвер (рис. 8). Простейшая форма
взаимоблокировки, представленная в функции Deadlock(), была в
этом режиме выявлена.
Рис. 8.
Аварийный дамп при блокировке на быстрых мьютексах
Локализацию ошибки в драйвере установить невозможно, однако
сама операционная система сформировала правило вызова систем-
ных функций (рис. 9).
Рис. 9.
Правило вызова системных функций
Рекомендуется подробно изучить дамп памяти. По сформулиро-
ванным в нем правилам можно установить локализацию ошибки.
