Проблемы с правильностью отображения причины краха в BlueScreenView

Недавно, я столкнулся с несоответствием в определении проблемного драйвера, который может быть причиной краха в Bluescreenview и Windbg, после чего задумался, а правильно ли вообще работает Bluescreenview? Давайте рассмотрим этот случай более подробно.

На одной из машин, очень часто возникали крахи системы. Администратор использовал bluescreenview для нахождения причины краха. Программа показала, что потенциальным виновником является ntkrnlpa.exe (то есть ядро системы), скриншот ниже.

Я попросил админа выполнить проверку с помощью windbg.exe, он прислал результаты проверки, которые содержали приблизительно следующее.

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:Program FilesDebugging Tools for Windows (x64)32015-10576-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: *** Invalid *** **************************************************************************** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * **************************************************************************** Executable search path is: ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y  argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* Unable to load image SystemRootsystem32
tkrnlpa.exe, Win32 error 0n2 *** WARNING: Unable to verify timestamp for ntkrnlpa.exe *** ERROR: Module load completed but symbols could not be loaded for ntkrnlpa.exe Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7601.18409.x86fre.win7sp1_gdr.140303-2144 Machine Name: Kernel base = 0x82c19000 PsLoadedModuleList = 0x82d625b0
Debug session time: Fri Mar 20 15:20:54.038 2015 (UTC + 3:00)
System Uptime: 0 days 0:38:47.411
*********************************************************************
....
Probably caused by : USBFilter.sys ( USBFilter+250f )

Followup: MachineOwner
---------

Finished dump check

То есть теперь, возможной причиной краха является драйвер USBFilter.sys. Но как видно из текста при использовании dumpchk.exe символы не были настроены должным образом. Была выполнена эта настройка, все что для этого необходимо – это добавить один параметр:

dumpchk.exe -y srv*C:Symbols*http://msdl.microsoft.com/download/symbols 032015-10576-01.dmp

Теперь dumpchk.exe в строке “caused by” указал совершенно другую информацию, скриншот ниже:

Конечно же аналигичный результат будет и в Windbg.exe, поскольку обе эти программы для нахождения причины краха используют один и тот же код из библиотеки dbghelp.dll.

Я вспомнил также о существовании одного онлайного сервиса анализа дампов — https://www.osronline.com/page.cfm?name=analyze и выполнил анализ с его помощью. Результат, который отличается от полученных ранее представлен на скриншоте ниже:

Таким образом:

  • хотя BlueScreenView является одним из наиболее простых и популярных приложений, которое позволяет определить обыкновенному пользователю причину возникновения синего экрана смерти BSOD, она в работает некорректно;
  • для анализа необходимо использовать средства Microsoft и обязательно настроить использование символов. Без них результат анализа может быть некорректным.
Понравилась статья? Поделиться с друзьями:
Добавить комментарий

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