Использование Driver Verifier для выявления проблемного драйвера

Утилита Driver Verifier (verifier.exe) предназначена для анализа проблемных драйверов, когда анализ дампов памяти после BSOD не позволяет найти проблемный драйвер. Driver Verifier – это “палочка выручалочка” в наиболее проблемных ситуациях.

С помощью Driver Verifier можно выполнять:

  • стресс тест драйвера (имитируются условия нехватки ресурсов);
  • контроль переполнения буфера;
  • контроль за ошибками, возникающими при неправильной работе при заданном IRQL;
  • анализ ошибок ввода-вывода;
  • детектирование ситуаций deadlock и т.д.

С полными возможностями утилиты можно ознакомится здесь — http://msdn.microsoft.com/en-us/library/windows/hardware/ff545470%28v=vs.85%29.aspx.

Утилита Driver Verifier  бывает очень полезной когда:

  • у администратора (пользователя) есть подозрения, что именно этот драйвер вызывает крах системы и он хочет дополнительно проверить так ли это на самом деле;
  • разработчики драйвера, хотят протестировать свой драйвер;
  • при анализе дампа после BSOD найти проблемный драйвер нельзя.

Одним из самых непростых случаев анализа дампов памяти является случай, когда драйвер ошибочно перезаписывает данные до начала или за концом буфера, выделенного им. В таких случаях, возникают ошибки в ядре ОС (например, анализ дампа после BSOD показывает, что ошибка возникла в ntoskrnl.exe).

Давайте посмотрим подобный случай на конкретном примере. С помощью утилиты NotMyfault вызываем BSOD — “Buffer overflow”.

Результат анализа дампа с помощью windbg во вложении ниже.

Согласно анализа дампа получаем.

1. Arg1: 00000007, Attempt to free pool which was already freed (была попытка освобождения уже освобожденного пула)

2. IMAGE_NAME:  ntkrpamp.exe (отношение к этому имеет само ядро системы)

Именно при подобных ошибках, на помощь приходит verifier.

Запускаем verifier.

Выбираем “Создать не стандартные параметры”. Далее выбираем “Выбрать параметры из списка”.

Выбираем все кроме “Имитация нехватки ресурсов”.

После чего выбираем “Выбрать незагруженные драйверы к этому списку” и указываем путь к драйверу myfault.sys, который находится в том же каталоге, что и программа NotMyfault.exe.

После чего отмечаем драйвер и нажимаем “Готово”. После этого, нам необходимо перегрузить компьютер.

Выполняем все те же действия, что и в начале. Запускаем NotMyfault.exe, выбираем “Buffer overflow” и нажимаем “Crash”. Как вы заметили крах может произойти не сразу, поскольку кто и когда будет пытаться работать с этой памятью неизвестно заранее. Как видим на изображении ниже, благодаря verifier система может определить проблемный драйвер.

Приведу анализ с помощью !analyze –v в windbg.exe дампа памяти после BSOD.

Программа verifier делает так, что проверяемый драйвер вместо обыкновенной памяти доступной в ядре использует специальный пул, предназначенный для определения подобной ошибки. Благодаря этому, можно найти драйвер, который приводит к BSOD.

Если посмотреть результаты анализа то мы видим следующее.

1. DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6) – это одна из ошибок, которая генерируется verifier

2. IMAGE_NAME:  myfault.sys – драйвер, который привел к проблеме.

Таким образом, если анализ дампа памяти после BSOD не позволяет найти “виновный драйвер” воспользуйтесь программой verifier.exe (установите все проверки, кроме нехватки памяти).

Verifier также поддерживает возможность работы из командной строки. Более подробную информацию по этой программе вы можете получить здесь — http://msdn.microsoft.com/en-us/library/windows/hardware/ff545448(v=vs.85).aspx

Наиболее простым вариантом использования Driver Verifier (verifier.exe) является его запуск со следующими параметрами:

verifier /standard /driver имя файла драйвера

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: