Компьютер зависает или перезагружается: диагностика ПК

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

Нерегулярный сбой трудно локализовать по одному симптому. Высокая температура может оказаться следствием нагрузки, общий статус SMART «хорошо» не описывает каждый вид проблемы накопителя, а событие Kernel-Power 41 само по себе не называет неисправный узел. Рабочая диагностика начинается с хронологии: что именно произошло, в какой момент и какие независимые показатели изменились непосредственно перед этим.

Цель проверки — не угадать деталь, а сформировать гипотезу, которую можно подтвердить повторяемым сценарием, журналом, дампом или проверкой конфигурации. Такой подход особенно полезен перед обращением по направлению Ремонт компьютеров: сохраненные данные помогают воспроизвести проблему и не начинать диагностику с перебора комплектующих.

Зависание, синий экран или мгновенный рестарт: три разных профиля сбоя

Фраза «компьютер выключился» объединяет несколько разных событий. При полном зависании изображение остается на экране, но система перестает реагировать. Синий экран означает, что Windows зарегистрировала критическую ошибку и показала код остановки. При мгновенном рестарте экран гаснет, после чего начинается загрузка системы. Отдельный профиль — полное отключение питания без автоматического запуска.

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

Для каждого эпизода следует записать:

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

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

Температуры CPU и GPU в простое и под нагрузкой: важна динамика, а не одно число

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

Сравнивать результаты следует только с ограничениями конкретных моделей CPU и GPU. Универсальной температуры, одинаково допустимой для всех процессоров и видеокарт, нет. Кроме того, программа мониторинга может показывать температуру отдельных ядер, кристалла, графического процессора или другую величину датчика. Эти строки нельзя механически приравнивать друг к другу или к пределу, указанному производителем для другого показателя.

Температурная гипотеза становится содержательнее, когда одновременно видны несколько признаков:

• температура растет вместе с нагрузкой и приближается к пределу конкретного компонента;
• рабочие частоты при продолжающейся нагрузке снижаются;
• скорость вентиляторов не меняется ожидаемым образом либо охлаждение работает нестабильно;
• сбой воспроизводится после похожего периода нагрузки;
• после изменения режима охлаждения меняется и поведение компьютера.

Даже такое совпадение сначала показывает корреляцию. Например, рост температуры CPU во время рендеринга закономерен сам по себе. Для проверки важен не факт нагрева, а связь между температурной динамикой, ограничением частот, работой вентиляторов и точным временем зависания или рестарта. Названия датчиков и предельные значения нужно сверять с документацией производителя процессора, видеокарты и используемой программы мониторинга.

SMART для SATA и NVMe: переназначенные сектора, media errors и critical warning

Общий индикатор состояния накопителя удобен как краткая сводка, но не заменяет просмотр отдельных счетчиков. Наборы данных у SATA- и NVMe-устройств различаются. Для SATA могут использоваться атрибуты, определенные производителем диска, включая сведения о переназначении секторов. У NVMe предусмотрена информация о состоянии, в которой отдельно рассматриваются critical warning и media errors. Поэтому одинаково названная строка в двух программах не обязательно имеет одинаковый смысл.

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

Логика сопоставления выглядит так:

• ошибка чтения сравнивается со счетчиками, определение которых связано с ошибками носителя или операциями ввода-вывода;
• переназначенные сектора оцениваются по документации производителя конкретного SATA-диска;
• media errors и critical warning рассматриваются как отдельные поля NVMe Health Information;
• исчезновение диска проверяется не только по SMART, но и по журналу, поведению контроллера и повторяемости события.

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

Ошибки RAM: код синего экрана, тест памяти и повторяемость на одном модуле

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

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

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

Результаты стоит записывать отдельно для каждой конфигурации. Формулировка «тест памяти нашел ошибку» недостаточна без сведений о слотах, модулях и настройках. Так же недостаточно считать RAM исправной только потому, что один короткий запуск теста завершился без сообщения: вывод должен учитывать повторяемость реального сбоя и остальные сигналы.

Kernel-Power 41, WHEA и дамп памяти: что сообщает каждая запись

Kernel-Power с идентификатором 41 фиксирует, что предыдущая работа Windows завершилась некорректно. Событие полезно для восстановления хронологии, но не является готовым диагнозом блока питания. Оно может появиться после внезапного отключения, аппаратного сброса, зависания с принудительной перезагрузкой или критической ошибки, после которой система перезапустилась.

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

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

Практический порядок чтения журнала таков:

1. Найти момент, записанный пользователем во время внешнего события.
2. Посмотреть записи непосредственно перед ним, а не только сообщения после загрузки.
3. Отделить Kernel-Power 41 от WHEA, bug check и событий приложений.
4. Проверить наличие кода остановки и дампа.
5. Сравнить время с журналом температур, нагрузкой и поведением накопителя.

Если Kernel-Power 41 появляется уже после запуска Windows, он сообщает о результате предыдущего сбоя. Причину следует искать в предшествующих данных и в условиях, при которых событие повторяется.

Сбой только в игре, рендеринге или простое: нагрузочный сценарий сужает круг узлов

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

Это не означает, что рестарт в игре автоматически доказывает неисправность видеокарты или блока питания. Сначала нужно проверить, повторяется ли событие в одной программе, зависит ли оно от версии драйвера, совпадает ли с ростом температур, снижением частот, ошибкой WHEA или исчезновением накопителя. Требования программы и драйвера следует сверять с их официальной документацией.

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

• совместная нагрузка CPU и GPU показывает поведение системы при их одновременной работе;
• нагрузка преимущественно на один компонент помогает проверить, сохраняется ли тот же профиль сбоя;
• операции с накопителем сопоставляются со SMART и дисковыми событиями;
• длительный простой сравнивается с настройками энергосбережения и моментом выхода из него.

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

Температура, SMART и код события совпали по времени: как формируется проверяемая гипотеза

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

• Событие: рестарт во время совместной нагрузки CPU и GPU. Показатель: температурная динамика, частоты, вентиляторы, Kernel-Power 41 и возможные предшествующие WHEA. Проверка: повторение сопоставимого сценария с сохранением телеметрии и без одновременного изменения нескольких настроек.
• Событие: зависание при чтении файлов. Показатель: задержки, дисковые записи Windows, полный SMART и изменение релевантных счетчиков. Проверка: диагностика накопителя официальной утилитой с предварительным сохранением важных данных.
• Событие: разные BSOD. Показатель: коды остановки, дампы и результаты теста памяти. Проверка: повторение на корректной конфигурации, проверка модулей и слотов по руководству платы.
• Событие: отключение без дампа. Показатель: отсутствие bug check, Kernel-Power 41 после загрузки и условия нагрузки. Проверка: анализ питания, охлаждения и аппаратных событий без объявления одной записи доказательством причины.

Совпадение во времени еще не равно доказанной причинности. Если температура выросла перед рестартом, требуется проверить, достигал ли именно наблюдаемый датчик ограничения конкретной модели и менялись ли частоты. Если одновременно увеличился счетчик SMART, нужно установить его официальное значение и связь с наблюдаемой операцией. Если в журнале есть WHEA, анализируют содержание события, а не только его наличие.

Минимальный комплект для дальнейшей диагностики включает время каждого эпизода, точное внешнее проявление, сценарий нагрузки, модель CPU, GPU и накопителя, журнал температур с частотами и вентиляторами, полный SMART, коды остановки, события Windows и доступные дампы. Также сохраняют конфигурацию RAM, активные профили и сведения о недавних изменениях драйверов или настроек.

Такой набор не обещает мгновенно назвать неисправную деталь, но позволяет проверять версии последовательно. Гипотеза о перегреве должна подтверждаться температурной динамикой и поведением частот; версия о накопителе — его счетчиками, журналом и характером операций; версия о памяти — повторяемым тестом и проверкой конфигурации; предположение о питании — отдельной аппаратной диагностикой, а не одним событием Kernel-Power 41.