Отсутствие записей в данном окне означает, что записанные дампы памяти отсутствуют, и вам придется подождать следующего сбоя для его изучения. (В предыдущих пунктах мы предоставили Windows инструкции по сохранению дампа памяти во время выхода из строя.) Если вы видите какие-либо записи в BlueScreenView, нажмите на интересующую вас запись (судя по дате и времени) и взгляните на нижнюю половину окна программы. Там будет показан список процессов и драйверов Windows, которые были активны во время сбоя, и, как правило, причина проблемы будет выделена красным цветом:
Введите название причины проблемы в свой поисковик и узнайте о ней всю необходимую информацию. Если это драйвер устройства, это означает, что вам необходимо обновить данный драйвер, как было описано в предыдущей главе, или, если текущий драйвер является бета-версией, вам необходимо перейти на использование последней официальной версии драйвера.
Предположим, вы выполнили поиск по названию, и он показал, что название соответствует процессу Windows, например ntoskrnl.exe. Поскольку вы недавно запустили проверку системных файлов и DISM/Readiness Tool, маловероятно, что данный системный файл поврежден. Скорее всего, сбой системы произошел когда ntoskrnl.exe работал с каким-либо сторонним драйвером или программным обеспечением. Чтобы определить такую стороннюю причину проблемы, нам необходимо использовать инструмент Windows под названием WinDbg (отладчик [дебаггер] Windows). Сначала загрузите программный пакет «Windows Software Development Kit» (SDK), соответствующий вашей операционной системе:
Windows 7 (SDK для Win8, приведённый ниже, также должен быть совместим):
http://www.microsoft.com/en-us/download/details.aspx?id=3138
Windows 8.1:
https://msdn.microsoft.com/en-US/windows/desktop/bg162891
Windows 10:
https://dev.windows.com/en-us/downloads/windows-10-sdk
После запуска скачанного средства установки оно предложит вам выбор параметров для установки. Выберите только «Debugging Tools for Windows» и уберите галочки со всех других опций:
Нажмите «Установить». После завершения установки нажмите клавишу Windows и введите «WinDbg» (без кавычек; в старых версиях Windows вам придется запустить утилиту «Выполнить» [клавиша «Пуск» → «Программы» → «Стандартные»] в качестве администратора и ввести «WinDbg»). Нажмите правой кнопкой мыши на WinDbgX64, если у вас 64-разрядная версия Windows (или WinDbgX86 для 32-разрядной версии) и выберите «Запуск от имени администратора»:
Нажмите «Да», если вы увидите предупреждение «Контроля учетных записей». Появится программное окно отладчика Windows. В меню «File» выберите «Symbol File Path…»:
В появившееся текстовое поле вставьте следующий код:
SRV*C: \Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Нажмите «ОК». Нажмите меню «File» и выберите «Save Workspace». Еще раз нажмите меню «File» и выберите «Open crash dump…». Найдите и выберите файл C: \Windows\MEMORY.DMP или, если он не существует, выберите один из файлов в папке C: \Windows\Minidump а затем нажмите «Открыть». Отладчик Windows начнет анализ данных (для чего требуется активное подключение к Интернету). Весь процесс займет 10–30 секунд. В нижней части текстового вывода вы увидите фразу: «Probably caused by…» («Возможной причиной является…»). Теперь вы можете использовать название данного процесса или драйвера для дальнейшего изучения сбоя системы. Если вы желаете просмотреть более подробный анализ (только для продвинутых пользователей), нажмите ссылку !analyze — v расположенную на несколько строк выше фразы «Probably caused by…» в выводном окне отладчика Windows.
Если вы видите сообщение «Probably caused by Unknown_Image (ANALYSIS_INCONCLUSIVE)», тогда вам необходимо убедиться, что в следующий раз Windows сохранит полный дамп памяти, как описано в начале данной главы. В следующий раз, когда вы увидите синий экран смерти, вы сможете проанализировать полный дамп памяти, расположенный в C: \Windows\MEMORY.DMP с помощью отладчика Windows.
Расследуем случаи зависания
Мне бы хотелось верить, что Windows становится все более стабильной с каждой новой версией. Но это не так. Свежевыпущенная операционная система (например, Windows 10 от 29 июля 2015 года: официальная дата выпуска) особенно уязвима в течение первых месяцев, поскольку она еще не была тщательно протестирована Майкрософтом. Так называемые апгрейды (большие обновления) Windows 10 и инсайдерские сборки Windows 10 менее стабильны и надежны, чем предыдущая сборка Windows 10.