[Petya V4sechkin]

Скажите BlueScreenView для анализа дампа использует средства Windows Debugging Tools или нет? (см скрин)

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

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 не выводит имя процесса, в котором произошёл сбой.

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

Probably caused by: amifldrv64.sys PROCESS_NAME: SCEWIN_64.exe

[Гризлик]

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

Скажите пожалуйтса откуда это взялось?

PROCESS_NAME: SCEWIN_64.exe

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

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

[Petya V4sechkin]

Но там тоже везде упоминается amifldrv64.sys. SCEWIN_64.exe в результатах не нашел.

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

И я правильно понимаю что BlueScreenView для анализа мало эфективен?

Да.

[Гризлик]

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

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

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

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

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

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

Код:

dumpchk -y C:\Symbols 1.dmp

[Petya V4sechkin]

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

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

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

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

[Гризлик]

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

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

[Petya V4sechkin]

Так вот с помощью дампа можно ли определить (хотя бы предположительно) виновную "железку"?

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

[Гризлик]

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