BSOD - [решено] Вопрос про Windows Debugging Tools и BlueScreenView

[Гризлик]

Здраствуйте!

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

Если это так то мне интерестно как это получается дамп один, а BlueScreen показывает драйвер nvlddmkm.sys, а Windows Debugging Tools показывает amifldrv64.sys. Кому верить?

Прилагаю дамп и скрины.

Вложения

dump.rar

(33.1 КБ) 0 скачиваний

dump.rar

(33.1 КБ) 0 скачиваний

Вложения

[Расширение jpg было запрещено, вложение больше недоступно.]

Вложения

[Расширение jpg было запрещено, вложение больше недоступно.]

Вложения

[Расширение jpg было запрещено, вложение больше недоступно.]

[Petya V4sechkin]

Цитата Гризлик:

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

По умолчанию нет.

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

Код:

Код: Выделить всё

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

в меню 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 для анализа мало эфективен?

Да.

[Гризлик]

Цитата Petya V4sechkin:



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

!analyze -v

BSOD - [решено] Вопрос про Windows Debugging Tools и BlueScreenView

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



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



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




Цитата Petya V4sechkin:



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

BSOD - [решено] Вопрос про Windows Debugging Tools и BlueScreenView

А как же скрин 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 бывает и по другим причинам). Ну и так далее.

Кроме того, надо смотреть всю цепочку вызовов в стеке.

[Гризлик]

Понятно.

Спасибо! Вопросы исчерпаны!