Проверка ошибок 0x139: KERNEL_SECURITY_CHECK_FAILURE
Проверка ошибок KERNEL_SECURITY_CHECK_FAILURE имеет значение 0x00000139. Эта проверка ошибок указывает, что ядро обнаружило повреждение критической структуры данных.
Внимание
Эта статья предназначена для программистов. Если вы являетесь клиентом, который получил код ошибки синего экрана при использовании компьютера, см. статью "Устранение неполадок синим экраном".
Параметры проверки ошибок 0x139 KERNEL_SECURITY_CHECK_FAILURE
| Параметр | Описание |
|---|---|
| 1 | Тип повреждения. Дополнительные сведения приведены в таблице ниже. |
| 2 | Адрес кадра ловушки для исключения, вызвавшего проверку ошибок |
| 3 | Адрес записи исключения для исключения, вызвавшего проверку ошибки |
| 4 | Зарезервировано |
В следующей таблице описываются возможные значения параметра 1.
| Параметр 1 | Description |
|---|---|
| 0 | Буфер на основе стека был перезаверщен (нарушение /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 | Повреждена запись RTL_BALANCED_NODE RBTree. |
| 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), используя расширение !analysis и !analysis.
Используйте журнал событий, чтобы узнать, существуют ли события более высокого уровня, которые происходят до этого кода остановки.
Эти общие советы по устранению неполадок могут оказаться полезными.
Если вы недавно добавили оборудование в систему, попробуйте удалить или заменить его. Или обратитесь к производителю, чтобы узнать, доступны ли какие либо исправления.
Если недавно были добавлены новые драйверы устройств или системные службы, попробуйте удалить или обновить их. Попробуйте определить, что изменилось в системе, вызвавшей появление нового кода проверки ошибок.
Проверьте системный журнал в Просмотр событий для получения дополнительных сообщений об ошибках, которые могут помочь определить устройство или драйвер, вызывающий ошибку. Дополнительные сведения см. в разделе "Открыть Просмотр событий". Ищите критические ошибки в системном журнале, которые появились примерно в то же время, что и "синий экран".
Просмотрите диспетчер устройств, чтобы узнать, помечены ли какие-либо устройства восклицательным знаком (!). Просмотрите журнал событий, отображаемый в свойствах драйвера для любого драйвера сбоя. Попробуйте обновить соответствующий драйвер.
Запустите программу обнаружения вирусов. Вирусы могут заразить все типы жестких дисков, отформатированных для Windows, и в результате повреждение диска может создать коды проверки системных ошибок. Убедитесь, что программа обнаружения вирусов проверяет главную загрузочную запись для инфекций.
Дополнительные общие сведения об устранении неполадок см. в разделе "Анализ данных с синим экраном".
См. также
Анализ аварийного дампа с помощью отладчиков Windows (WinDbg)