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

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

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

Это важно

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

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

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

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

Параметр 1 Описание
0 Буфер на основе стека был переполнен (нарушение устаревшего /GS).
1 Код инструментария VTGuard обнаружил попытку использования нелегальной виртуальной таблицы функций. Как правило, объект C++ был поврежден, а затем была предпринята попытка вызова виртуального метода с использованием указателя this поврежденного объекта.
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, а целевое значение не находилось в доверенном системном кусте.
10 Проверка защиты от косвенного вызова обнаружила недействительную передачу управления.
11 Проверка защиты от записи обнаружила недопустимую запись в память.
12 Была предпринята попытка переключиться на неверный контекст фабрина.
13 (тринадцать) Была предпринята попытка назначить недопустимый контекст регистра.
14 Счетчик ссылок для объекта недопустим.
18 Была предпринята попытка переключиться на недопустимый контекст jmp_buf.
19 Была внесена небезопасная модификация данных, доступных только для чтения.
20 Не удалось провести криптографическую самодиагностику.
двадцать один Обнаружена недопустимая цепочка исключений.
двадцать два Произошла ошибка криптографической библиотеки.
двадцать три Был сделан неверный вызов из DllMain.
двадцать четыре Обнаружен неверный адрес базы образа.
двадцать пять При защите при импорте задержки загрузки произошла неустранимая ошибка.
26 Был сделан звонок на небезопасный добавочный номер.
двадцать семь Была вызвана устаревшая служба.
28 Был обнаружен доступ к буферу за пределами границы.
29 Запись RTL_BALANCED_NODE RBTree была повреждена.
37 Был вызван вход в таблицу прыжков переключателя вне диапазона.
38 Была предпринята попытка выполнить longjmp по неверной цели.
39 Подавленный при экспорте целевой объект вызова не может быть назначен действительным адресатом вызова.

Причина

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

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

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

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

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

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

Резолюция

Для определения причины этих проблем обычно требуется использование отладчика для сбора дополнительной информации. Следует проверить несколько файлов дампа, чтобы определить, имеет ли этот стоп-код схожие характеристики, такие как код, который выполняется при появлении стоп-кода.

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

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

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

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

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

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

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

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

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

См. также

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

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