Синий экран раз в несколько дней: читаем дамп, а не гадаем

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

Если загуглить этот код, интернет предложит стандартный набор: проверить память, обновить драйвер видеокарты, прогнать sfc, переустановить Windows. Любой из этих советов может сработать, а может отнять полдня и ничего не дать. Мы тоже начали с гипотезы: на машине стояли два средства защиты, а их драйверы-фильтры любят конфликтовать. Звучало убедительно. И было неправдой.

Сначала факты: когда и сколько раз

Windows записывает каждое падение в журнал. Одна команда показывает всю историю:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 1001 } |
  Where-Object ProviderName -eq 'Microsoft-Windows-WER-SystemErrorReporting' |
  Select-Object TimeCreated, Message |
  Format-List

И проверяем, что дамп памяти вообще сохранился, без него разговор будет коротким:

Get-Item C:\Windows\MEMORY.DMP -ErrorAction SilentlyContinue
Get-ChildItem C:\Windows\Minidump -ErrorAction SilentlyContinue

Дамп

Дамп — это снимок памяти в момент падения. В нём записано, какой код выполнялся и кто кого вызвал. Читается он отладчиком Microsoft. Удобнее всего консольным cdb, который ставится вместе с Debugging Tools for Windows: можно запустить анализ и уйти пить чай.

mkdir C:\dumps -Force | Out-Null
& "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe" `
    -z C:\Windows\MEMORY.DMP `
    -c ".symfix; .reload; !analyze -v; q" > C:\dumps\analyze.txt

Полный дамп разбирается небыстро: отладчик скачивает символы с серверов Microsoft, и в окне долго висит *BUSY*. Когда анализ закончился, в файле analyze.txt нас интересуют четыре строки:

MODULE_NAME:       RvNetMP60
IMAGE_NAME:        RvNetMP60.sys
PROCESS_NAME:      RvControlSvc.exe
FAILURE_BUCKET_ID: 0x139_3_CORRUPT_LIST_ENTRY_RvNetMP60!unknown_function

Гадать больше не о чём. RvNetMP60.sys — драйвер виртуального сетевого адаптера Radmin VPN, RvControlSvc.exe — его служба. Гипотеза про конфликт защитных программ отправилась в корзину.

Что именно произошло

Стек вызовов читается снизу вверх и рассказывает историю целиком:

nt!NtClose                  ← программа закрывает дескриптор
nt!IopDeleteFile            ← ядро удаляет объект файла
ndis!ndisCloseIrpHandler    ← сетевая подсистема закрывает адаптер
RvNetMP60+0x197d            ← управление уходит в драйвер Radmin VPN
RvNetMP60+0x2572            ← int 29h: аварийная остановка

При закрытии соединения драйвер пытался удалить из списка в памяти ядра элемент, который уже был удалён. Windows проверяет такие списки на целостность и, поймав повреждение, намеренно останавливает систему, чтобы испорченная память не пошла дальше. Инструкция int 29h с подкодом FAST_FAIL_CORRUPT_LIST_ENTRY означает именно это: не случайный сбой, а сработавшую проверку.

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

Лечение

Если программа не нужна, удаляем её, а затем проверяем, что за ней не остался драйвер. Удаление через «Программы и компоненты» иногда оставляет .sys в хранилище драйверов:

pnputil /enum-drivers | Select-String -Context 2,3 'Famatech'
# в выводе находим Published Name вида oemNN.inf и удаляем:
pnputil /delete-driver oemNN.inf /uninstall /force

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

Что нашлось по дороге

Раз уж залезли глубоко, посмотрели и на остальное. sfc /scannow нашёл и починил повреждённые системные файлы. DISM при восстановлении образа падал с «Ошибка: 2». А сама система оказалась Windows 10 версии 1903, поддержка которой закончилась в 2020 году. В выводе отладчика была стандартная для 0x139 фраза о том, что такое повреждение памяти теоретически позволяет получить контроль над машиной. Признаком взлома это не является, но на системе без обновлений безопасности это лишний аргумент обновиться. Мы вынесли это заказчику отдельным пунктом, а не стали «чинить втихую».

Что из этого вынести

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