Що саме не проходить перевірку
Ядро тримає контрольні суми та інваріанти для своїх критичних структур — приблизно як банк, що звіряє книги кілька разів на секунду. Код зупинки 0x139 означає, що одна з таких звірок не зійшлася: вказівник списку більше не вказує, куди зобов'язаний, або заголовок буфера більше не відповідає його вмісту. Windows зупиняється навмисно, бо працювати далі зі зіпсованим станом ядра — ризик записати сміття по всьому диску.
Псує ці структури здебільшого щось прозаїчне. Пам'ять, що видає перевернуті біти під навантаженням — найчастіше профіль XMP чи EXPO, який працює за межами того, що контролер пам'яті справді тримає, — лідер. Драйвери, що пишуть за межами своїх буферів, на другому місці, і серед них рецидивісти — драйвери GPU та антивірусів. Пошкоджені системні файли й помираючий SSD, що віддає спотворені дані під час читання, доповнюють список.
- Нестабільна RAM — профілі XMP/EXPO за межами того, що справді тримає контролер пам'яті CPU
- Збійний драйвер, що пише за межами буфера — рецидивісти: драйвери GPU, антивірусів і віртуалізації
- Системні файли, пошкоджені невдалим оновленням або раптовим знеструмненням
- Помираючий SSD, який віддає спотворені дані при читанні, — видно в атрибутах SMART
- Агресивний андерволт або розгін, що перевертає біти під навантаженням
Перевірка пам'яті та відновлення файлів
Почніть із пам'яті: вона і найчастіша причина, і найдешевша для виключення. Запустіть mdsched.exe, перезавантажтеся на запит і дайте стандартному проходу відпрацювати; вирок з'явиться в «Перегляді подій» — «Журнали Windows» → «Система», джерело MemoryDiagnostics-Results. Стандартний прохід ловить лише грубі відмови, тому якщо збої тривають при чистому результаті, вимкніть XMP/EXPO у BIOS і тестуйте модулі по одному, перш ніж видавати пам'яті виправдання.
Файли — наступний щабель, уже з «Термінала (Адміністратор)»: sfc /scannow звіряє захищені файли зі сховищем компонентів, потім DISM /Online /Cleanup-Image /RestoreHealth лагодить саме сховище, якщо SFC не зміг виправити все, потім chkdsk C: /f /r під час наступного перезавантаження проходить по поверхні диска. Чиста перевстановлення драйвера GPU завершує програмну частину — завантажте свіжий пакунок, видаліть старий у «Параметрах» → «Застосунки» → «Встановлені застосунки» та поставте новий після перезавантаження.
Пошук повторюваного винуватця
Якщо код зупинки пережив усе це, збій достатньо специфічний, щоб назвати ім'я. Мінідампи в C:\Windows\Minidump несуть адресу збою та список завантажених модулів; WinDbg із командою !analyze -v або читач на кшталт BlueScreenView перетворює їх на ім'я драйвера, і це ім'я завершує полювання. Програмам, встановленим за кілька днів до початку збоїв, належить перший допит — їх видалення слугує і тестом, і лікуванням.
Знаряддя останнього шансу — Driver Verifier (verifier /standard /all з консолі адміністратора), який змушує підозрілі драйвери падати на власних баґах — голосно й негайно. Він навмисно небезпечний: чекайте синіх екранів, поки він працює, і пам'ятайте вихід — завантажтеся в безпечний режим і виконайте verifier /reset, щоб його вимкнути. У таких руках Verifier викурює причаївся драйвер за день-два.
Питання та відповіді
KERNEL SECURITY CHECK FAILURE — це ознака вірусу?
Занадто рідко. Перевірка ловить пошкодження, а не зараження, і причини майже завжди в залізі та драйверах. Руткіт, що псує дані, можливий, але він у самому кінці списку.
Чи може погана пам'ять викликати KERNEL_SECURITY_CHECK_FAILURE?
Так — це найчастіша окрема причина. Запустіть mdsched.exe, потім вимкніть XMP/EXPO і тестуйте модулі по одному, якщо збої не вщухають.
Як зупинити KERNEL_SECURITY_CHECK_FAILURE під час завантаження?
Завантажтеся в безпечний режим із WinRE («Параметри завантаження» → клавіша 4), видаліть те, що встановили останнім, і проганяйте SFC і DISM — за вами в безпечний режим збій рідко піде.
Перевірте склад ліцензії до покупки.
Разовий 30-хвилинний тест охоплює базові функції. Інструменти з позначкою PRO залишаються заблокованими до активації платної ліцензії.
Читайте також
Написати нам: [email protected]