Ко мне обратилось сразу несколько человек с вопросом, стоит ли вместо
Debugging Tools for Windows использовать для анализа дампов памяти
относительно недавно вышедшую утилиту BlueScreenView. Бесплатные утилиты NirSoft
(автор – Nir Sofer) хорошо известны своей полезностью, удобством и
продуманностью функционала. И BlueScreenView действительно очень удобна
для определения проблемного драйвера.
BlueScreenView
Увеличить рисунок
По умолчанию она ищет дампы в папке %systemroot%\Minidump, но можно настроить и собственную папку (Options –> Advanced). Для найденных драйверов утилита отображает:
- В
верхней панели – название файла, дату создания, название стоп-ошибки,
код ошибки, параметры, а также драйвер, предположительно вызвавший
проблему (Caused By Driver).
- В нижней панели – (в зависимости от настроек в Options –> Lower Pane Mode)
все драйверы, загруженные во время ошибки, или только драйверы,
найденные в стеке. Среди всех драйверов - на розовом фоне отображаются
предположительно вызвавшие проблему драйверы. Также, утилита может
отображать синий экран, очень похожий на тот, который все так любят.
Важно! Я должен отметить, что при определении драйвера не нужно полагаться только на имя файла в столбце Caused by Driver.
Следует рассмотреть драйверы в нижней панели (или только выделенные
розовым цветом, если включено отображение всех драйверов), в первую
очередь обращая внимание на несистемные драйверы.
Утилита очень
быстро работает, а также обладает дополнительными возможностями по
копированию отдельных строк и созданию HTML-отчетов.
BlueScreenView vs. kdfe.cmd / WinDbg
В приведенном выше скриншоте виновником проблемы являлся не USBPORT.SYS (системный драйвер), aclaudsl.sys (драйвер модема). Именно на последний указал анализ kdfe,
полагающeгося на Debugging Tools for Windows. И тут я перехожу к
вопросу, насколько корректен анализ утилиты по сравнению с kdfe /
WinDbg.
Честно говоря, я не являюсь экспертом по отладке, но одно
очевидно сразу: в отличие от WinDbg, BlueScreenView не использует для
анализа символы, загружаемые с сайта Microsoft. Я поинтересовался у
автора программы, насколько корректным считает он анализ в этих
условиях. И вот что он ответил (в сокращении):
Вне зависимости
от того, используете вы BlueScreenView или WinDbg с символами,
невозможно достичь абсолютной точности в определении драйвера.
Я
не думаю, что символы помогли бы моей утилите произвести более точный
анализ. В символах содержится дополнительная информация, которая может
помочь профессионалам определить точную причину - например, функцию
внутри драйвера, вызвавшую ошибку. Однако определение драйверов,
вовлеченных в ошибку, может быть выполнено на основе адресов памяти без
всяких символов.
Я решил проверить, насколько результаты BlueScreenView совпадают с kdfe. Поскольку в материале
нет недостатка, я взял навскидку полтора десятка дампов с наиболее
распространенными кодами (0x8E, 0x50, 0xD1 и 0x0A). Лишь в одном случае
результаты отличались – BlueScreenView указала на системный драйвер, а
kdfe – на драйвер Outpost Firewall. Тестирование также выявило, что
далеко не всегда BlueScreenView верно указывает на проблемный драйвер в
верхней панели, но во всех случаях кроме одного, оговоренного выше,
проблемный драйвер был обозначен в нижней панели. Таким образом, kdfe
понятнее указывает на проблемный драйвер. Однако наблюдалась и обратная
картина – иногда kdfe однозначно указывает на системный драйвер, в то
время как BlueScreenView выделяет еще и несистемные, которые также могут
оказаться причиной проблемы.
Резюме
Я
вполне могу порекомендовать BlueScreenView для быстрого анализа дампов
памяти, создающихся при BSOD. Однако утилита не всегда однозначно
указывает на проблемный драйвер в верхней панели. Поэтому, вместо того
чтобы любоваться в нижней панели картинкой синего экрана, лучше включить
для нее отображение драйверов и изучить их список. В неочевидных
случаях лучше также провести анализ с kdfe, а для глубокого анализа без WinDbg все равно не обойтись.
