Синий экран оставляет улики и как прочитать их в малом дампе памяти

Синий экран обрывает работу внезапно и пугающе: всё замирает, появляется сообщение о критической ошибке, машина перезагружается, а несохранённое пропадает. Первая реакция большинства это паника и беспомощность, ведь экран мелькнул и исчез, оставив лишь тревогу и непонимание. Но за этой пугающей внезапностью скрывается важная правда: синий экран не просто ломает работу, он оставляет улики. В момент сбоя система записывает на диск слепок того, что происходило, малый дамп памяти, и в этом слепке хранится ключ к причине. Научиться читать эти улики значит превратить пугающую загадку синего экрана в диагностируемую и устранимую проблему.

Синий экран это не каприз и не случайность, а защитная реакция системы на критическую ошибку, которую она не может безопасно пережить. Столкнувшись с чем-то фатальным, скажем сбойным драйвером, залезшим в чужую память, система предпочитает аварийно остановиться, чем продолжать работу в повреждённом состоянии, рискуя данными. И перед остановкой она оставляет запись о случившемся: код ошибки на экране и подробный слепок в дампе. Эти две улики, код и дамп, и ведут к причине. Понять, как их добыть и прочитать, значит овладеть диагностикой едва ли не самого пугающего класса проблем, перед которым большинство пасует.

Настройка записи малого дампа памяти

Прежде всего надо убедиться, что система вообще записывает дампы при сбоях, ведь без них улик не будет. Запись малого дампа управляется настройками загрузки и восстановления. Проверить и настроить это можно через свойства системы, в параметрах загрузки и восстановления, где задают тип записываемого дампа. Для диагностики синих экранов достаточно малого дампа, компактного слепка с ключевой информацией о сбое. Открыть нужные параметры можно прямой командой:

SystemPropertiesAdvanced

В параметрах загрузки и восстановления выбирают запись малого дампа памяти, и тогда при каждом синем экране система будет сохранять слепок. Управляется это и через реестр, что удобно для настройки на множестве машин. Включение записи малого дампа через реестр выглядит так:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v CrashDumpEnabled /t REG_DWORD /d 3 /f

Значение для малого дампа велит системе сохранять компактный слепок при сбоях. Без этой настройки синие экраны проходят бесследно, не оставляя улик, и диагностировать их нечем. Поэтому первый шаг к разбору синих экранов это убедиться, что запись дампа включена, иначе придётся ждать следующего сбоя уже с настроенной записью, потеряв улики первого.

Где живут дампы и как их найти

Малые дампы система складывает в особую папку, и знать её расположение необходимо для разбора. Дампы сохраняются в подпапку системного каталога, каждый с именем, отражающим дату сбоя. Найти все имеющиеся дампы можно запросом содержимого этой папки:

Get-ChildItem C:\Windows\Minidump\*.dmp | Sort-Object LastWriteTime -Descending

Эта команда выводит все дампы, отсортированные от свежих к старым, и сразу видно, когда случались сбои и сколько их было. Сама по себе частота и регулярность сбоев это уже улика: участившиеся дампы говорят об обостряющейся проблеме, а единичный давний о разовом сбое. Отсутствие же дампов при жалобах на синие экраны означает либо что запись не была включена, либо что сбой случается на стадии, когда дамп не успевает записаться.

Стоит понимать и случаи, когда дамп не создаётся, чтобы не искать несуществующее. Если отказала дисковая подсистема, системе некуда писать дамп, и его не будет. Если критическая ошибка случилась в самом начале загрузки, до готовности механизма записи, дампа тоже не выйдет. В этих случаях улику ищут иначе, по коду на экране и по журналу, а не в несуществующем дампе. Понимание, когда дамп есть, а когда его не бывает, избавляет от напрасных поисков слепка там, где его в принципе не могло возникнуть.

Код остановки из журнала как первая улика

Даже не вскрывая дамп, многое говорит код остановки, который система записывает в журнал при каждом синем экране. Этот код это первая и легкодоступная улика, нередко сразу сужающая круг причин. Выборка событий о критических сбоях из журнала через PowerShell достаёт эти коды:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} | Where-Object {$_.Message -like "*bugcheck*"} | Select-Object TimeCreated, Message

Здесь из журнала берутся события о проверке на сбой, в которых записан код остановки и сопутствующие параметры. Этот код это отправная точка диагностики: каждый код соответствует определённому классу причин, и зная его, уже понимаешь, в какую сторону копать. Одни коды указывают на драйверы, другие на память, третьи на оборудование. Сам по себе код редко даёт точный диагноз, но он направляет дальнейший поиск, отсекая целые классы причин и указывая на вероятные.

Помимо кода в журнале часто видно и время сбоя, что важно для сопоставления с другими событиями. Зная, когда случился синий экран, заглядывают в журнал на момент перед ним и нередко находят там предвестники: ошибки драйвера, сбои устройства, предупреждения, приведшие к фатальному сбою. Это сопоставление кода остановки с предшествующими событиями журнала и есть первый уровень анализа, доступный без всякого вскрытия дампа, и нередко его одного хватает, чтобы выйти на причину.

Вскрытие дампа отладчиком для точного диагноза

Когда кода остановки мало, вскрывают сам дамп специальным отладчиком, дающим точную картину сбоя. Отладчик загружает дамп, разбирает запечатлённое в нём состояние и указывает на виновника, чаще всего на конкретный сбойный драйвер. Главная команда анализа в отладчике запускает автоматический разбор дампа, который сам находит вероятную причину:

!analyze -v

Эта команда проводит подробный анализ дампа и выдаёт развёрнутый отчёт: код остановки с расшифровкой, вероятный виновный модуль, стек вызовов на момент сбоя. Чаще всего в отчёте прямо назван файл драйвера, вызвавший крах, и это и есть искомый виновник. Зная конкретный сбойный драйвер, проблему лечат прицельно: обновляют его, откатывают, удаляют проблемное устройство. Это и есть точный диагноз, ради которого вскрывают дамп, в отличие от общих указаний кода остановки.

Для работы отладчика нужны отладочные символы, особые данные, помогающие расшифровать содержимое дампа, и их обычно подгружают автоматически. Без символов анализ менее точен, ведь отладчику труднее сопоставить адреса в дампе с именами модулей. Поэтому отладчик настраивают на загрузку символов, и тогда его отчёт читается ясно, с именами драйверов вместо голых адресов. Эта деталь с символами объясняет, почему иногда анализ дампа выходит невнятным: символы не подгрузились, и отладчику нечем расшифровать улики, отчего отчёт пестрит адресами вместо понятных имён.

Истолкование результатов и типичные виновники

Получив указание на виновника, важно верно его истолковать, ведь названный модуль не всегда и есть корень. Отладчик показывает, в чьём коде случился сбой, но иногда сбойный модуль лишь жертва, а виноват другой, повредивший память до него. Поэтому к названному виновнику относятся как к главному подозреваемому, а не к окончательному приговору, проверяя версию дальнейшими действиями. Чаще всего, впрочем, названный драйвер и есть причина, особенно если он сторонний, а не системный.

Типичные виновники синих экранов укладываются в несколько групп, и знание их направляет диагностику. Драйверы оборудования это самый частый источник, особенно свежеустановленные или, наоборот, устаревшие, конфликтующие с системой. Сбойная оперативная память даёт синие экраны, разбросанные по разным кодам без явной закономерности, ведь портится случайное содержимое. Проблемы накопителя, перегрев, нестабильное питание тоже приводят к сбоям. Сопоставляя код остановки, указанного виновника и обстоятельства, сужают круг до конкретной причины из этих групп.

Полезна и закономерность появления сбоев для диагностики. Синий экран при определённом действии, скажем при подключении устройства или запуске программы, прямо указывает на связанный с этим действием драйвер или компонент. Случайные же сбои без привязки к действиям чаще говорят о железе, памяти или перегреве. Анализ того, когда и при каких обстоятельствах появляется синий экран, дополняет улики из дампа и журнала, и вместе они складываются в диагноз. Эта триада, код остановки, разбор дампа и закономерность появления, и ведёт от пугающей загадки синего экрана к понятной и устранимой причине.

Проверка памяти и выявление сбойного драйвера активными средствами

Когда дамп указывает на память или сбои разбросаны по разным кодам без закономерности, подозрение падает на оперативную память, и её проверяют активно. Система несёт штатное средство проверки памяти, прогоняющее тесты при перезагрузке. Запуск проверки памяти выполняется командой:

mdsched

Эта команда предлагает перезагрузиться и прогнать тесты памяти, которые при сбойных модулях выявят ошибки. Сбойная память коварна тем, что даёт разнообразные и непредсказуемые синие экраны, ведь портит случайное содержимое, и обычный анализ дампа тут может указывать каждый раз на разное. Поэтому при разбросанных без закономерности сбоях проверка памяти это обязательный шаг, отсекающий или подтверждающий её как причину, прежде чем копать в драйверах.

Когда же подозрение на драйвер, но какой именно, неясно, помогает штатное средство проверки драйверов, которое нагружает их особым образом, заставляя сбойный проявиться. Запуск настройки проверки драйверов делается командой:

verifier

Это средство включает усиленную проверку драйверов, при которой проблемный драйвер быстрее вызовет синий экран с чётким указанием на себя, чем при обычной работе. Это мощный, но обоюдоострый инструмент: он намеренно провоцирует сбои проблемных драйверов, отчего машина может чаще падать в синий экран, пока виновник не выявлен. Поэтому проверку драйверов включают осознанно, понимая, что она ради выявления виновника временно делает сбои чаще, и отключают, как только драйвер найден.

Стоит обращаться со средством проверки драйверов осторожно, ведь неумелое его применение способно ввести машину в цикл синих экранов при загрузке. Если проверка выявила проблемный драйвер, и система стала падать сразу при старте, её отключают через среду восстановления, сбросив настройки проверки. Поэтому перед включением этого средства разумно иметь путь к отступлению, понимая, как отключить проверку, если машина перестанет нормально загружаться. Эта предосторожность отличает грамотное применение мощного инструмента от безрассудного, способного превратить разовые сбои в постоянную невозможность загрузиться.

Закономерности во времени и связь с изменениями системы

Мощный приём диагностики синих экранов это связать их появление с изменениями в системе во времени. Синие экраны редко начинаются на ровном месте, чаще их появление совпадает с каким-то событием: установкой драйвера, обновлением, подключением оборудования, установкой программы. Выявив момент, когда сбои начались, и вспомнив, что менялось тогда же, нередко сразу выходят на причину. Сопоставление дат дампов с историей изменений системы и есть этот приём.

Историю установки обновлений и изменений система хранит, и её сопоставляют с датами сбоев. Если синие экраны начались сразу после некоторого обновления или установки драйвера, виновник почти найден, и лечение сводится к откату этого изменения. Просмотр недавних изменений системы в сочетании с датами дампов мгновенно выявляет такие совпадения. Этот метод корреляции во времени работает там, где прямой анализ дампа невнятен, ведь он опирается не на содержимое сбоя, а на обстоятельства его появления, которые порой красноречивее самого дампа.

Полезно держать и общий принцип: при внезапно начавшихся синих экранах первый вопрос это что изменилось в системе незадолго до их появления. Новое оборудование, свежий драйвер, недавнее обновление, установленная программа, любое из этих изменений могло стать причиной. Откатив подозрительное изменение и проверив, прекратились ли сбои, подтверждают или отметают версию. Этот подход от изменений, при котором ищут не в абстрактных недрах системы, а среди недавних перемен, нередко выводит на причину быстрее тщательного анализа дампа, ведь большинство синих экранов на прежде стабильной машине растут именно из недавних изменений, а не из ниоткуда.

Синий экран перестаёт быть пугающей необъяснимой катастрофой, стоит понять, что он оставляет улики, по которым восстанавливают причину. Код остановки из журнала направляет поиск, указывая класс причины, разбор малого дампа отладчиком называет конкретного виновника, чаще всего сбойный драйвер, а закономерность появления сбоев уточняет картину. Настроив запись дампов заранее, зная, где они лежат, и владея их разбором, диагност превращает внезапный крах из источника паники в рядовую диагностическую задачу с понятным алгоритмом. И тогда синий экран, прежде вызывавший лишь беспомощную тревогу, становится отправной точкой спокойного расследования, которое почти всегда выводит на вполне конкретную и устранимую причину, скрытую в оставленных системой уликах.