Вопрос про Windows Debugging Tools и BlueScreenView
Вложений: 4
- 1.jpg (226.50 KB, скачиваний: 19)
- 2.jpg (48.10 KB, скачиваний: 20)
- 3.jpg (170.70 KB, скачиваний: 17)
- dump.rar (33.10 KB, скачиваний: 22)
Здраствуйте!
У меня вопрос. Скажите BlueScreenView для анализа дампа использует средства Windows Debugging Tools или нет? (см скрин)
Если это так то мне интерестно как это получается дамп один, а BlueScreen показывает драйвер nvlddmkm.sys, а Windows Debugging Tools показывает amifldrv64.sys. Кому верить?
Прилагаю дамп и скрины.
|
| Petya V4sechkin |
28-04-2018 20:12 2811207 |
Цитата:
Цитата Гризлик
Скажите 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 |
28-04-2018 21:06 2811214 |
Цитата:
Цитата Гризлик
Но там тоже везде упоминается amifldrv64.sys. SCEWIN_64.exe в результатах не нашел.
|
И драйвер, и процесс упоминаются в результате команды:
!analyze -v
Цитата:
Цитата Гризлик
И я правильно понимаю что BlueScreenView для анализа мало эфективен?
|
Да. |
Цитата:
Цитата Petya V4sechkin
И драйвер, и процесс упоминаются в результате команды:
!analyze -v »
|
Извиняйте. Это я слепой. Действительно имеется такая строчка.
Вы меня уж извините за нудные вопросы. Но просто хочется правильно дампы научится читать:)
Получатеся виновник всетаки amifldrv64.sys, а SCEWIN_64.exe это всего лишь родитель. Т.е. SCEWIN_64.exe обратился к amifldrv64.sys и это вызвало ошибку. Я правильно понимаю?
Цитата:
Цитата Petya V4sechkin
И кстати, dumpchk.exe не выводит имя процесса, в котором произошёл сбой. »
|
А как же скрин 3 в начале темы. Выделено красным. Ведь это результат команды
Код:
dumpchk -y C:\Symbols 1.dmp
|
| Petya V4sechkin |
28-04-2018 22:20 2811219 |
Гризлик, можно и так сказать, хотя в данном случае SCEWIN_64.exe и amifldrv64.sys относятся к одной и той же утилите для прошивки BIOS.
В общем случае не обязательно происходит обращение напрямую, может быть и опосредованная цепочка вызовов в стеке.
Цитата:
Цитата Гризлик
А как же скрин 3 в начале темы. Выделено красным. Ведь это результат команды
|
Ну вы разницу между процессом и драйвером не теряйте. Красным выделен драйвер, процесса там нет.
|
Petya V4sechkin, Спасибо еще раз.
И еще один вопрос (если можно) который меня мучает. :)
Если анализ дампа ссылается на ntoskrnl.exe. Это зачастую сигнализирует о "железной" проблеме (хотя это может быть конечно вызвано глюком самой системы или косячной сборки). Так вот с помощью дампа можно ли определить (хотя бы предположительно) виновную "железку"? Потому что коды ошибок (в BSOD) тоже в основном дает расплывчатую информацию.
|
| Petya V4sechkin |
28-04-2018 23:35 2811226 |
Цитата:
Цитата Гризлик
Так вот с помощью дампа можно ли определить (хотя бы предположительно) виновную "железку"?
|
Смотря какая "железка". Если это память, сбои абсолютно случайные (с разными кодами, на разных драйверах). Если процессор, может быть 0x124. Если дисковая подсистема, 0x7A или 0xF4 (хотя 0xF4 бывает и по другим причинам). Ну и так далее.
Кроме того, надо смотреть всю цепочку вызовов в стеке. |
Понятно.
Спасибо! Вопросы исчерпаны!:)
|
Время: 23:04.
© OSzone.net 2001-
