Вопрос про Windows Debugging Tools и BlueScreenView
 

Здраствуйте!
У меня вопрос. Скажите BlueScreenView для анализа дампа использует средства Windows Debugging Tools или нет? (см скрин)
Если это так то мне интерестно как это получается дамп один, а BlueScreen показывает драйвер nvlddmkm.sys, а Windows Debugging Tools показывает amifldrv64.sys. Кому верить?
Прилагаю дамп и скрины.

По умолчанию нет.
Чтобы корректно использовал, надо:

1. добавить в опциях параметр -y для загрузки символов, например:
   
   Код:

   ---

   "C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\dumpchk.exe" -y srv*C:\Symbols*http://msdl.microsoft.com/download/symbols "%1"

   ---

2. в меню Options -> Lower Pane Mode -> DumpChk Output (F9)

И кстати, dumpchk.exe не выводит имя процесса, в котором произошёл сбой.

Конкретно у вас:

Petya V4sechkin, Понятно. Спасибо!

Скажите пожалуйтса откуда это взялось? Сделал анализ по этой инструкции. Но там тоже везде упоминается amifldrv64.sys. SCEWIN_64.exe в результатах не нашел. (имеется ввиду что в дапме не нашел. Сам файл то на диске имеется).

П.С.
И я правильно понимаю что BlueScreenView для анализа мало эфективен? В большинстве случаев показывает бред.

И драйвер, и процесс упоминаются в результате команды:
!analyze -v

Да.

Извиняйте. Это я слепой. Действительно имеется такая строчка.

Вы меня уж извините за нудные вопросы. Но просто хочется правильно дампы научится читать:)

Получатеся виновник всетаки amifldrv64.sys, а SCEWIN_64.exe это всего лишь родитель. Т.е. SCEWIN_64.exe обратился к amifldrv64.sys и это вызвало ошибку. Я правильно понимаю?

А как же скрин 3 в начале темы. Выделено красным. Ведь это результат команды

Гризлик, можно и так сказать, хотя в данном случае SCEWIN_64.exe и amifldrv64.sys относятся к одной и той же утилите для прошивки BIOS.

В общем случае не обязательно происходит обращение напрямую, может быть и опосредованная цепочка вызовов в стеке.

Ну вы разницу между процессом и драйвером не теряйте. Красным выделен драйвер, процесса там нет.

Petya V4sechkin, Спасибо еще раз.

И еще один вопрос (если можно) который меня мучает. :)
Если анализ дампа ссылается на ntoskrnl.exe. Это зачастую сигнализирует о "железной" проблеме (хотя это может быть конечно вызвано глюком самой системы или косячной сборки). Так вот с помощью дампа можно ли определить (хотя бы предположительно) виновную "железку"? Потому что коды ошибок (в BSOD) тоже в основном дает расплывчатую информацию.

Смотря какая "железка". Если это память, сбои абсолютно случайные (с разными кодами, на разных драйверах). Если процессор, может быть 0x124. Если дисковая подсистема, 0x7A или 0xF4 (хотя 0xF4 бывает и по другим причинам). Ну и так далее.
Кроме того, надо смотреть всю цепочку вызовов в стеке.

Понятно.
Спасибо! Вопросы исчерпаны!:)