До недавних пор я думал, что единственный способ узнать о причине BSOD'а – это белые буковки на синем «экране смерти». Недавние события немного расширили мои познания в области диагностирования неполадок, и этими знаниями я хочу поделиться с вами, хабражители.
Случилась очередная поломка системы у очередного клиента. «Синий экран, и нечего не шевелится» — так описала проблему девушка, которая за компьютером работала. Дело было около 18 вечера, и ехать на выезд совсем не хотелось. Перезвонив клиенту, я сказал, что компьютер посмотрю удаленно, хотя сам понимал, что заниматься ним придется завтра. Тем не менее совесть не дала просто забыть о компе до завтра.
Единственная разумная мысль, которая у меня тогда возникла, почитать Event Viewer, что и сделал.
Вот приблизительно такая запись привлекла мое внимание. Ну, раз система сгенерила багчек, почему бы его не почитать.
Я немного погуглил на предмет открыть файл «.dmp», и наткнулся на Debugging Tools for Windows. Это часть большого продукта Microsoft Windows SDK for Windows 7. Зачем искать решения на стороне, когда их предоставляет сам разработчик. На установку Debugging Tools (как и на установку .NET Framework 4, который необходим для работы) ушло совсем немного времени. Естественно, что при установке я не выбирал дополнительных компонентов, а то мое удалённое диагностирование затянулось бы надолго (см. скрин)
Понимаю, что использовать инструмент с таким огромным функционалом только для того, чтобы посмотреть на .dmp файл не совсем правильно, но, кроме этого, мне он и не нужен.
Итак – программа установлена, осталось только посмотреть на сам минидамп. Для этого запускаем WinDbg из пакета Debugging Tools for Windows, и в меню «File» выбираем «Open crash dump».
После недолгого анализа программа выдает предположительную причину вызова BSOD.
В моем случае, причиной был неверный драйвер Storage Controller’а. Скачав с оф.сайта свежий драйвер, причину неработоспособности удалось побороть.
К сожалению, причины неполадок зачастую не лежат на поверхности, и вот такой вот анализ может не принести желаемого результата.
Случилась очередная поломка системы у очередного клиента. «Синий экран, и нечего не шевелится» — так описала проблему девушка, которая за компьютером работала. Дело было около 18 вечера, и ехать на выезд совсем не хотелось. Перезвонив клиенту, я сказал, что компьютер посмотрю удаленно, хотя сам понимал, что заниматься ним придется завтра. Тем не менее совесть не дала просто забыть о компе до завтра.
Единственная разумная мысль, которая у меня тогда возникла, почитать Event Viewer, что и сделал.
Вот приблизительно такая запись привлекла мое внимание. Ну, раз система сгенерила багчек, почему бы его не почитать.
Я немного погуглил на предмет открыть файл «.dmp», и наткнулся на Debugging Tools for Windows. Это часть большого продукта Microsoft Windows SDK for Windows 7. Зачем искать решения на стороне, когда их предоставляет сам разработчик. На установку Debugging Tools (как и на установку .NET Framework 4, который необходим для работы) ушло совсем немного времени. Естественно, что при установке я не выбирал дополнительных компонентов, а то мое удалённое диагностирование затянулось бы надолго (см. скрин)
Понимаю, что использовать инструмент с таким огромным функционалом только для того, чтобы посмотреть на .dmp файл не совсем правильно, но, кроме этого, мне он и не нужен.
Итак – программа установлена, осталось только посмотреть на сам минидамп. Для этого запускаем WinDbg из пакета Debugging Tools for Windows, и в меню «File» выбираем «Open crash dump».
После недолгого анализа программа выдает предположительную причину вызова BSOD.
В моем случае, причиной был неверный драйвер Storage Controller’а. Скачав с оф.сайта свежий драйвер, причину неработоспособности удалось побороть.
К сожалению, причины неполадок зачастую не лежат на поверхности, и вот такой вот анализ может не принести желаемого результата.
