Шесть недель зависаний, ни одного дампа и 44 байта нулей

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

Сначала аномалия проявлялась раз в неделю. Затем — каждые пару дней. К середине июля счётчик дошел до трех раз за сутки.

Однако хуже самой нестабильности было полное отсутствие диагностических следов. Ни дампов памяти, ни минидампов, ни BSOD, ни единой записи WHEA-Logger. В системном журнале красовалось лишь стандартное событие Event 41 (Kernel-Power) с формулировкой «система была перезагружена, завершив работу некорректно» и нулевым кодом ошибки BugcheckCode = 0. Операционная система даже не успевала осознать собственный крах.

Диагностировать было нечего. В сухом остатке имелось лишь дорогостоящее «железо» в состоянии клинической смерти и абсолютный вакуум улик.

Забегая вперед, отмечу: виновником оказалась вовсе не оперативная память, не устаревшие драйверы и не блок питания, хотя поочередно под подозрение попадали все три компонента. Корень зла крылся в интерфейсе PCIe Gen5. Полготора месяца мучений решились изменением ровно одного параметра в BIOS.

Для понимания контекста приведу конфигурацию системы: материнская плата ASUS ProArt X870E-CREATOR WIFI, процессор Ryzen 9 9950X3D, 64 ГБ оперативной памяти стандарта DDR5 и видеокарта RTX 5080. Компьютер используется в гибридном режиме: днем — для тяжелых расчетов, компиляции и обработки данных, а по вечерам — в качестве игровой станции.

Безмолвный труп

Первым делом я отправился изучать журнал событий Windows и обнаружил ровно то, чего опасался больше всего: девять инцидентов с кодом Event 41 за последние девяносто дней и полное отсутствие каких-либо дампов. Никаких MEMORY.DMP, минидампов, следов в LiveKernelReports, записей WHEA или TDR.

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

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

Таким образом, штатные средства мониторинга оказались бесполезны. Журналы пусты, дампы не сформированы, а воспроизвести баг по требованию невозможно — он возникал спонтанно с интервалом в несколько часов или дней.

Свидетеля пришлось создавать своими руками

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

Я написал компактный скрипт на PowerShell примерно из пятнадцати строк. Каждые двадцать секунд он опрашивает утилиту nvidia-smi, забирая актуальные метрики — температуры, энергопотребление, частоты, степень загрузки, обороты вентиляторов и состояние питания (pstate), после чего дописывает полученные данные в CSV-файл:

$q = 'timestamp,name,temperature.gpu,temperature.memory,power.draw,power.limit,' +
'utilization.gpu,utilization.memory,clocks.gr,clocks.mem,fan.speed,pstate'
while ($true) {
$now = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
$line="nvidia-smi-error,,,,,,,,,,"
try {
$out = & $smi --query-gpu=$q --format=csv,noheader,nounits 2>$null | Select-Object -First 1
if ($out) { $line = ($out -replace '^[^,]*,', '') }
} catch { }
Add-Content -Path $csv -Value ("{0},{1}" -f $now, $line) -Encoding utf8
Start-Sleep -Seconds 20
}
Критически важный нюанс здесь заключается в использовании командлета Add-Content на каждой итерации вместо постоянно открытого потока StreamWriter. Буферизованный вывод при жестком зависании безвозвратно теряется: вся информация остается в оперативной памяти процесса и кэше файловой системы, физически не доходя до накопителя. Нам же необходимо, чтобы каждая строка мгновенно фиксировалась на диске, ведь вся ценность эксперимента сводится именно к самому последнему успешному кадру телеметрии.
Оставалось лишь добавить скрипт в планировщик задач при старте системы и запастись терпением. Ждать, впрочем, пришлось недолго.
Первая зацепка: видеокарта пала, но компьютер устоял
Шестого июля в 14:11 лог зафиксировал следующую картину:
2026-07-06 14:10:54, NVIDIA GeForce RTX 5080, 37, N/A, 36.68, 360.00, 0, 1, 262, 15001, 0, P0,
2026-07-06 14:11:14, NVIDIA GeForce RTX 5080, 38, N/A, 36.41, 360.00, 0, 1, 277, 15001, 0, P0,
2026-07-06 14:11:34,No devices were found,
2026-07-06 14:11:54,No devices were found,
2026-07-06 14:12:14,No devices were found,
Последний корректный опрос: 38 °C, 36 Ватт энергопотребления, нулевая загрузка графического чипа, 277 МГц по ядру, кулеры остановлены. Абсолютно холодный режим простоя. Спустя двадцать секунд графический ускоритель исчезает из системы.
Этот инцидент позволил сразу исключить из списка подозреваемых две версии. Перегрев отпадает полностью — 38 градусов. Просадки напряжения по питанию под нагрузкой также исключены — видеокарта потребляла лишь 36 Ватт из 360 возможных.
Однако самое удивительное заключалось в другом. Обнаружив пропажу устройства, логгер не прекратил работу. Он продолжил исправно фиксировать строку «No devices were found» каждые двадцать секунд — и делал это на протяжении последующих двадцати одного часа без единого сбоя, пока наутро я не добрался до кнопки Reset.
Иными словами, операционная система вовсе не умирала. Windows продолжала функционировать, планировщик задач отрабатывал циклы, скрипт PowerShell тикал, а файловая система принимала входящие данные. Скончалась исключительно видеокарта — она отвалилась от шины PCIe и перестала отвечать на запросы. Все это время машина продолжала работать вслепую, лишенная вывода изображения.
Это означало, что моя первоначальная гипотеза о «зависании процессора» была ошибочной — по крайней мере, в данном конкретном сценарии.
Вторая улика: 44 байта нулевых байтов
Следующий сбой, произошедший на следующий день, выглядел иначе. В этот оборвался и сам логгер, прекратив любые записи.
Анализ файла на байтовом уровне открыл весьма любопытную картину:
02e4c4   20 31 35 30 30 31 2c 20 30 2c 20 50 30 2c 0d 0a    15001, 0, P0,..
02e4d4   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
02e4e4   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
02e4f4   00 00 00 00 00 00 00 00 00 00 00 00 23 20 2d 2d   ............# --
02e504   2d 2d 20 77 61 74 63 68 64 6f 67 20 73 74 61   -- watchdog sta
После штатной строки и символов завершения строки CRLF шла последовательность ровно из 44 нулевых байтов. Сразу за ними следовала метка повторного запуска логгера после перезагрузки.
Эти нули не являются случайным мусором или повреждением файловой структуры. Это цифровой автограф жесткого прерывания питания в процессе записи. Драйвер файловой системы NTFS успел зарезервировать пространство под новую строку, но сами данные остались в кэше и не успели записаться на диск из-за мгновенного отключения питания. При штатном завершении работы кэш сбрасывается корректно; при экстренном обесточивании — нет. Отсюда и образовалась «пустота» из нулей, длина которой тютелька в тютельку совпала с размером недописанной строки.
В этот раз в журналах зафиксировались и Event 41, и Event 6008. Видеокарта вновь находилась в холодном состоянии: 34 °C, 35 Ватт, простой.
Таким образом, передо мной предстали два принципиально разных сценария отказа. В первом случае погибала одна лишь видеокарта при живой системе. Во втором — вся машина целиком вырубалась в долю секунды. Долгое время я расценивал это как две независимые проблемы, и это было моей второй ошибкой.
Почти две недели подозрений в адрес памяти
Дальнейший этап поиска включал проверку теорий, и кандидат в виде оперативной памяти выглядел наиболее убедительно.
Комплект из 64 ГБ DDR5, состоящий из двух двухранговых модулей, работал на EXPO-профиле с частотой 6000 MT/s против штатных 4800 MT/s. Для платформы AM5 это классический сценарий: процессорный контроллер памяти, нагруженный четырьмя ранками на повышенной частоте, регулярно провоцирует зависания в простое без синих экранов и дампов. Симптоматика на 100% совпадала с моей. Любой тематический форум по архитектуре AM5 первым делом рекомендует отключить профиль EXPO, и в большинстве случаев этот совет оказывается верным.
Я деактивировал EXPO, откатившись на стандарт JEDEC 4800. Протестировал систему в таком режиме несколько дней.
Результат — зависание. Повторилось дважды.
Следовательно, оперативная память оказалась ни при чем. Заодно из списка подозреваемых был вычеркнут видеодрайвер: я обновил ПО с январской сборки на самую свежую, но машина продолжила падать с прежней регулярностью.
Три версии, каждая из которых казалась железобетонной, рассыпались при проверке. Что осталось в сухом остатке? Единственный общий знаменатель для всех инцидентов — потеря связи видеокарты с шиной PCIe во время простоя.
Развязка оказалась банальной
Если графический адаптер теряет линк в режиме бездействия, оставаясь при этом холодным и потребляя минимум энергии, то корень проблемы кроется не в самом чипе и не в силовой части, а непосредственно в линии связи.
Первым делом я отключил функцию энергосбережения шины PCIe в Windows — ASPM (Link State Power Management), переведя соответствующие параметры в powercfg в положение «Off» как для питания от сети, так и от батареи. Логика проста: если линии связи уходят в спячку и не могут корректно пробудиться, запретим им засыпать вовсе. На следующее утро компьютер завис снова. Не помогло.
Оставалось воздействовать на скорость интерфейса. Флагманская RTX 5080 в слоте материнской платы X870E работала по протоколу PCIe Gen5 со скоростью 32 GT/s на линию. Я зашел в BIOS и принудительно ограничил режим работы слота до поколения Gen4.
С тех пор прошло четырнадцать суток без единого события Event 41. И это на фоне прежней статистики с тремя падениями в сутки.
Пазл сложился, объединив оба симптома в единую цепь. Первопричина заключалась в том, что графический адаптер терял линк в простое. Если после этого процессор обращался к исчезнувшему устройству посредством немедленного чтения MMIO (Memory-Mapped I/O), он зависал в ожидании ответа навсегда — поскольку ответа физически не могло поступить, а отменить такую транзакцию архитектурно нельзя. Ядро системы зависало глухо, обработчик прерываний не запускался, дамп писать было некому (отсюда и BugcheckCode = 0). Жесткие перезагрузки не были отдельным недугом, а выступали лишь следствием основного сбоя: повезло — ОС пережила отвал видеокарты; не повезло — какой-то фоновый процесс обратился к «мертвому» железу, уронив всю систему.
Сделаю ремарку для особо щепетильных комментаторов. Я эмпирически доказал, что проблема крылась именно в Gen5: принудительно переключился на Gen4, и сбои прекратились. Почему конкретно этот экземпляр железа не вывозил стандарт Gen5 — вопрос открытый: особенности разводки печатной платы, микродефект контакта в слоте, неудачный кремний графического чипа или процессорного контроллера. Вариантов масса, но разделять их у меня нет никакого желания.
И, если честно, желания проводить дальнейшие эксперименты тоже нет. Чтобы проверить гипотезу с физическим контактом, пришлось бы переустанавливать видеокарту — то есть своими руками лезть в единственную конфигурацию, которая впервые за полтора месяца работает стабильно. Увольте.
Чек-лист для тех, кто столкнулся с аналогичной проблемой
Характерные симптомы, при которых стоит подозревать эту аномалию: спонтанные ресеты или зависания в состоянии покоя, событие Event 41 с кодом BugcheckCode = 0, полное отсутствие дампов и записей WHEA на современных платформах с поддержкой PCIe Gen5 (процессоры Ryzen 7000/9000 или Intel Core 12-14 поколений / Core Ultra в паре с видеокартами серии RTX 40/50 или Radeon RX 7000).
Для диагностики первым делом проверьте текущий режим работы шины с помощью команды:
nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.gen.max,pcie.link.width.current --format=csv
Дальнейшие шаги выполняйте в порядке от простых программных методов к аппаратным:


Отключение ASPM в Windows — через утилиту powercfg деактивируйте Link State Power Management для PCI Express. Мне это не помогло, но проверка занимает ровно минуту.


Принудительный перевод слота в режим Gen4 в BIOS. На материнских платах ASUS этот параметр находится в разделе конфигурации подсистемы PCI (названия могут варьироваться: «PCIe Link Speed» или отдельные пункты для каждого слота, ищите упоминания поколения Gen). Именно эта манипуляция решила проблему.


Проверка применения настроек. Параметр pcie.link.gen.max в выводе диагностической утилиты должен измениться на четвёрку. Сброс настроек CMOS незаметно вернет спецификацию Gen5 на место, и вы не заметите подвоха до следующего зависания.


Переподключение видеокарты и проверка силовых кабелей — если предыдущие пункты не дали результата.


Скриншот: пункт BIOS с принудительным ограничением скорости слота до Gen4
И да, потеря производительности при переходе с Gen5 на Gen4 на современных игровых ускорителях равна погрешности: разница в играх укладывается в доли процента и не фиксируется без специализированных бенчмарков. Я потерял от этого компромисса настолько ничтожно мало, что возвращаться на Gen5 у меня нет ни малейшего намерения.
В сухом остатке
Полторы недели я упорно копал в сторону оперативной памяти. Гипотеза выглядела здраво: профили EXPO на платформе AM5 действительно способны вызывать схожие симптомы, и на моем месте любой поступил бы точно так же. Проблема заключалась лишь в том, что истинная причина была иной. Отбросить ошибочное предположение удалось исключительно с помощью контрольного эксперимента — отключением функции и ожиданием повторного сбоя.
А созданный мной диагностический логгер, кстати, тихо скончался еще три дня назад. Заметил я это только тогда, когда сел оформлять эту статью.



 

Источник