#Что происходит и когда подходит инструкция
Эта инструкция о Windows 10 посвящена отличию ошибок аппаратных компонентов — процессора, шины PCIe, питания и накопителей — от типичных сбоев драйверов по временнóй последовательности событий. Запись Kernel-Power 41 сама по себе не определяет причину; результаты нужно сопоставлять с дампом и признаками оборудования.
#Как отличить причины по признакам
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| WHEA-Logger и аппаратная подсистемаWindows может регистрировать подтверждённую или исправленную аппаратную ошибку. | События WHEA-Logger повторяются около сбоя, указан компонент/источник. | Сохранить полный текст и проверить поддержку оборудования. |
| BugCheck и сторонний драйверНекоторые критические ошибки возникают после изменения драйвера ядра. | Есть событие 1001 и одинаковый сторонний модуль в нескольких дампах. | Сверить недавние изменения, осторожно откатить конкретный драйвер. |
| Внезапная потеря питанияПеребой питания может не создать корректный дамп и код STOP. | Компьютер выключается резко, есть 41/6008, но нет BugCheck. | Проверить питание и состояние оборудования, не делать вывод по одному 41. |
#Пошаговые действия
- Сохраните сведения именно о критической остановкеВ Windows 10 нажмите Win+R →
winver, запишите номер сборки и дату первого сбоя. Если появился синий экран, сфотографируйте точный STOP-код, имя файла.sys, время и действие непосредственно перед ним. Если экран просто зависает или приложение закрывается без синего экрана, это другой тип неисправности; не объявляйте его BSOD. Сохраните открытые документы и не провоцируйте аварии многократно. - Сопоставьте журнал Windows со временем аварииПосле успешной загрузки нажмите Win+R →
eventvwr.msc→ «Журналы Windows» → «Система». Выберите «Фильтр текущего журнала» и найдите события 41, 1001, 6008 по времени. Изучите источник и полный текст события: Kernel-Power 41 лишь указывает на нештатный перезапуск, а BugCheck 1001 может содержать код и путь дампа. Если событий нет, это не доказывает исправность оборудования. - Составьте хронологию трёх последних случаевНажмите Win+R →
eventvwr.msc→ «Журналы Windows» → «Система». В фильтре задайте 41, 1001, 6008 и отдельно найдите события источника WHEA-Logger. Для каждого времени запишите источник, идентификатор, полное сообщение и был ли на экране STOP-код. Не удаляйте журнал и не смешивайте записи за разные даты. - Отличите подтверждённую ошибку от фразы Kernel-PowerОткройте событие 41 и посмотрите BugcheckCode: ненулевое значение может быть признаком ошибки остановки, но ноль не гарантирует аппаратную причину. Найдите событие BugCheck 1001 рядом по времени: оно может назвать дамп и код. 6008 лишь фиксирует нештатное завершение, поэтому одного его недостаточно для диагноза.
- Проверьте содержание записей WHEA-LoggerВ журнале «Система» найдите источник WHEA-Logger и откройте текст сообщения: там иногда указаны тип устройства, источник ошибки или идентификатор процессора/PCI Express. Наличие исправляемых ошибок не всегда равно неисправности железа; запишите частоту повторения и модель устройства. Не выключайте WHEA или журналирование ради «лечения».
- Сопоставьте драйверы и время их обновленияОткройте «Диспетчер устройств» → свойства компонентов, меняемых перед ошибкой → «Драйвер»: запишите поставщика, версию, дату. При нескольких однотипных BugCheck откройте минидампы в WinDbg и выполните
!analyze -v, не считая строку Probably caused by окончательным диагнозом. Если имена модулей каждый раз разные, проверьте аппаратные признаки. - Используйте безопасные признаки накопителя и питанияЕсли компьютер отключается при нагрузке, пахнет перегретым или SSD пропадает из UEFI, не провоцируйте повторную аварию и не выполняйте большие проверки записи. Сначала сохраните доступные данные. Для ноутбука запишите, было ли питание от батареи или сети, для ПК — состояние подключений; разбор блока питания требует сервиса, не вскрывайте его.
- Сформулируйте проверяемую гипотезу, а не диагноз наугадСведите в таблицу три колонки: дата и действие, событие с точным источником, версия драйвера/изменение оборудования. Если после согласованного отката одного драйвера сбои прекратились, это аргумент в его пользу; если WHEA продолжает появляться — нужна отдельная диагностика оборудования. Не объявляйте «сломана память» только из-за ntoskrnl.exe.
- Проверяйте по одному изменению, без опасного воспроизведенияПосле каждого безопасного действия выполните одну обычную перезагрузку и используйте компьютер в привычном режиме. Только при отсутствии риска для данных осторожно повторите исходную операцию один раз. Запишите, исчезли ли BSOD, и сравните новые сообщения в «Журналы Windows» → «Система». Если ошибка вернулась, прекратите эксперименты и восстановите последнюю изменённую настройку.
- Соберите данные для изготовителя или специалистаОткройте Проводник, введите в адресную строку
%SystemRoot%\Minidumpи найдите.dmpнужной даты. Скопируйте его в закрытую папку и приложите STOP-код, номер сборки, время, модель устройства и журнал изменений. Дампы могут содержать личные сведения; не выкладывайте их в открытый доступ. Если дамп не создан, так и укажите, не формируйте фиктивный отчёт.
#Команды для упомянутых проверок
Каждая команда относится только к описанному шагу. Перед вводом сверяйте среду запуска и права: командная строка Windows, командная строка WinRE и окно отладчика — разные среды.
Windows · Командная строка (CMD)Команда
Обычная Windows 10, окно Win+R, права пользователя достаточны для просмотра доступных журналов; открывает «Просмотр событий». Вывод зависит от политики аудита.
eventvwr.mscТекстКоманда
Запускается в командном поле установленного WinDbg после открытия копии .dmp, не в cmd. Показывает предварительный анализ кода STOP, модуля и стека.
!analyze -v#Как понять, что проблема решена
Результатом является не отсутствие одной записи, а достоверная последовательность: конкретный компонент или драйвер, подтверждённая связь с событием и отсутствие новых BSOD после безопасного исправления. Если доказательств нет, диагноз остаётся предварительным.
#Если действия не помогли
Продолжайте только по выявленной причине: точная модель, версия драйвера, код остановки и файл дампа важнее случайных универсальных советов. Если компьютер падает при обычной работе, прекратите тесты и сделайте резервную копию, когда это безопасно.