Поделиться через

Проверка ошибок 0x139: KERNEL_SECURITY_CHECK_FAILURE

Проверка ошибок KERNEL_SECURITY_CHECK_FAILURE имеет значение 0x00000139 и указывает, что ядро обнаруживает повреждение критической структуры данных.

Это важно

Эта статья предназначена для программистов. Если вы являетесь клиентом, получающим код ошибки синего экрана при использовании компьютера, см. статью "Устранение неполадок синим экраном".

Проверка ошибок 0x139 KERNEL_SECURITY_CHECK_FAILURE параметрами

Параметр Описание
1 Вид коррупции. Дополнительные сведения см. в следующей таблице.
2 Адрес кадра ловушки для исключения, вызвавшего проверку на ошибку
3 Адрес записи об исключении для исключения, вызвавшего проверку на наличие ошибки
4 Зарезервировано

В следующей таблице описаны возможные значения параметра 1.

Параметр 1 Описание
0 Переполнение буфера на основе стека (нарушение /GS устаревшего файла /GS).
1 Код инструментария VTGuard обнаружил попытку использования нелегальной виртуальной таблицы функций. Как правило, объект C++ поврежден, а затем вызов виртуального метода пытается использовать этот указатель поврежденного объекта.
2 Код инструментирования файлов cookie стека обнаружил переполнение буфера на основе стека (нарушение /GS).
3 LIST_ENTRY поврежден (например, двойное удаление). Дополнительные сведения см. в следующем разделе Причина.
4 Зарезервировано
5 Недопустимый параметр был передан в функцию, которая считает недействительные параметры фатальными.
6 Загрузчик неправильно инициализировал файл cookie безопасности стека. Эта ошибка вызвана созданием драйвера для запуска только в Windows 8 и попыткой загрузить образ драйвера в более ранней версии Windows. Чтобы избежать проблемы, необходимо создать драйвер для запуска в более ранней версии Windows.
7 Был запрошен фатальный выход из программы.
8 Проверка границ массива, вставленная компилятором, обнаружила операцию незаконного индексирования массива.
9 Был выполнен вызов RtlQueryRegistryValues , указывающий RTL_QUERY_REGISTRY_DIRECT без RTL_QUERY_REGISTRY_TYPECHECK, а целевое значение не было в доверенной системе hive.
10 Проверка защиты от косвенного вызова обнаружила недействительную передачу управления.
11 Проверка защиты от записи обнаружила недопустимую запись в память.
12 Была предпринята попытка переключиться на неверный контекст фабрина.
13 Была предпринята попытка назначить недопустимый контекст регистра.
14 Счетчик ссылок для объекта недопустим.
18 Была предпринята попытка переключиться на недопустимый контекст jmp_buf.
19 Была внесена небезопасная модификация данных, доступных только для чтения.
20 Не удалось провести криптографическую самодиагностику.
21 Обнаружена недопустимая цепочка исключений.
22 Произошла ошибка криптографической библиотеки.
23 Был сделан неверный вызов из DllMain.
24 Обнаружен неверный адрес базы образа.
25 При защите при импорте задержки загрузки произошла неустранимая ошибка.
26 Был сделан звонок на небезопасный добавочный номер.
27 Была вызвана устаревшая служба.
28 Был обнаружен доступ к буферу за пределами границы.
29 Повреждена запись RBTree RTL_BALANCED_NODE.
37 Был вызван вход в таблицу прыжков переключателя вне диапазона.
38 Была предпринята попытка выполнить longjmp по неверной цели.
39 Подавленный при экспорте целевой объект вызова не может быть назначен действительным адресатом вызова.

Причина

Используя таблицу 1 параметра и файл дампа, можно сузить причину многих проверок ошибок этого типа.

LIST_ENTRY коррупции может быть трудно отслеживать. Эта проверка ошибок указывает, что несоответствие было введено в двудвойный связанный список (обнаружено при добавлении или удалении отдельного элемента записи списка из списка). К сожалению, несоответствие не обязательно обнаруживается в то время, когда произошло повреждение, поэтому для выявления первопричины может потребоваться некоторая детективная работа.

Распространенные причины повреждения записей в списке включают:

  • Драйвер повредил объект синхронизации ядра, например KEVENT (например, двойной инициализации KEVENT, пока поток по-прежнему ждет этого же KEVENT, или позволяет KEVENT на основе стека выйти из области, пока другой поток использовал этот KEVENT). Этот тип проверки на наличие ошибок обычно выполняется в nt! Ke* или nt! Ki* код. Это может произойти, когда поток завершает ожидание объекта синхронизации или когда код пытается перевести объект синхронизации в сигнальное состояние. Как правило, сигналируемый объектом синхронизации является тот, который поврежден. Иногда средство проверки драйверов с особым пулом может помочь отслеживать виновника (если поврежденный объект синхронизации находится в блоке пула, который уже освобожден).
  • Драйвер повреждает периодический KTIMER. Этот тип проверки на наличие ошибок обычно выполняется в nt! Ke* или nt! Ki* и включает в себя подачу сигнала на таймер, либо вставку или удаление таймера из таблицы таймеров. Таймер, управляемый, может быть поврежденным, но может потребоваться проверить таблицу таймера с помощью таймера !timer (или вручную ходить по ссылкам списка таймеров), чтобы определить, какой таймер поврежден. Иногда средство проверки драйверов с специальным пулом может помочь отслеживать виновника (если поврежденный KTIMER находится в блоке пула, который уже освобожден).
  • Драйвер неправильно использует внутренний список связанных LIST_ENTRY стилей. Типичным примером может быть двойной вызов RemoveEntryList для одной и той же записи списка без повторной вставки записи списка между двумя вызовами RemoveEntryList . Возможны и другие варианты, такие как двойная вставка записи в один и тот же список.
  • Драйвер освобождает структуру данных, содержащую LIST_ENTRY без удаления структуры данных из соответствующего списка, что приводит к обнаружению повреждения позже после повторного использования старого блока пула.
  • Драйвер использовал список стилей LIST_ENTRY одновременно без надлежащей синхронизации, что приводит к оторванной обновлению списка.

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

Поскольку многие системные компоненты внутренне используют списки LIST_ENTRY, различные типы неправильного управления ресурсами драйвером, использующим системные API, могут привести к повреждению связанного списка в связанном списке, управляемом системой.

Резолюция

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

Дополнительные сведения см. в разделах Анализ аварийного дампа с помощью отладчиков Windows (WinDbg),Использование расширения !analyze и !analyze.

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

Эти общие советы по устранению неполадок могут быть полезны.

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

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

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

  • Посмотрите в Диспетчере устройств , помечены ли какие-либо устройства восклицательным знаком (!). Просмотрите журнал событий, отображаемый в свойствах драйвера, для любого неисправного драйвера. Попробуйте обновить соответствующий драйвер.

  • Запустите программу обнаружения вирусов. Вирусы могут заразить все типы жестких дисков, отформатированных для Windows, и в результате повреждение диска может создать коды проверки системных ошибок. Убедитесь, что программа обнаружения вирусов проверяет главную загрузочную запись на наличие инфекций.

  • Дополнительные сведения об устранении неполадок см. в разделе "Анализ данных синим экраном" для проверки ошибок.

См. также

Анализ аварийного дампа с помощью отладчиков Windows (WinDbg)

Анализ файла дампа Kernel-Mode с помощью WinDbg

  • Last updated on