Verificação de bugs 0x139: KERNEL_SECURITY_CHECK_FAILURE
A verificação de bugs KERNEL_SECURITY_CHECK_FAILURE tem um valor de 0x00000139. Essa verificação de bug indica que o kernel detectou a corrupção de uma estrutura de dados crítica.
Importante
Este artigo é para programadores. Se você for um cliente que recebeu um código de erro de tela azul enquanto estava usando o computador, confira Solucionar problemas de erros de tela azul.
Verificação de bugs 0x139 KERNEL_SECURITY_CHECK_FAILURE parâmetros
| Parâmetro | Descrição |
|---|---|
| 1 | O tipo de corrupção. Para obter mais informações, confira a tabela a seguir. |
| 2 | O endereço do quadro de interceptação para a exceção que causou a verificação de bugs |
| 3 | Endereço do registro de exceção para a exceção que causou a verificação de bugs |
| 4 | Reserved |
A tabela a seguir descreve os valores possíveis para o parâmetro 1.
| Parâmetro 1 | Descrição |
|---|---|
| 0 | Um buffer baseado em pilha foi saturado (violação de /GS herdada). |
| 1 | O código de instrumentação VTGuard detectou uma tentativa de usar uma tabela de funções virtual ilegal. Normalmente, um objeto C++ foi corrompido e, em seguida, uma chamada de método virtual foi tentada usando o ponteiro this. |
| 2 | O código de instrumentação do cookie de pilha detectou um estouro de buffer baseado em pilha (violação /GS). |
| 3 | Um LIST_ENTRY foi corrompido (por exemplo, uma remoção dupla). Para obter mais informações, consulte a seção Causa a seguir. |
| 4 | Reserved |
| 5 | Um parâmetro inválido foi passado para uma função que considera parâmetros inválidos fatais. |
| 6 | O cookie de segurança do cookie de pilha não foi inicializado corretamente pelo carregador. Isso pode ser causado pela criação de um driver para ser executado somente no Windows 8 e pela tentativa de carregar a imagem do driver em uma versão anterior do Windows. Para evitar esse problema, você deve criar o driver para ser executado em uma versão anterior do Windows. |
| 7 | Uma saída fatal do programa foi solicitada. |
| 8 | Uma verificação de limites de matriz inserida pelo compilador detectou uma operação ilegal de indexação de matriz. |
| 9 | Uma chamada para RtlQueryRegistryValues foi feita especificando RTL_QUERY_REGISTRY_DIRECT sem RTL_QUERY_REGISTRY_TYPECHECK e o valor de destino não estava em um hive de sistema confiável. |
| 10 | A verificação de proteção de chamada indireta detectou uma transferência de controle inválida. |
| 11 | A verificação de proteção de gravação detectou uma gravação de memória inválida. |
| 12 | Foi feita uma tentativa de alternância para um contexto de fibra inválido. |
| 13 | Foi feita uma tentativa de atribuir um contexto de registro inválido. |
| 14 | A contagem de referência para um objeto é inválida. |
| 18 | Foi feita uma tentativa de alternância para um contexto jmp_buf inválido. |
| 19 | Uma modificação não segura foi feita nos dados somente leitura. |
| 20 | Um autoteste criptográfico falhou. |
| 21 | Uma cadeia de exceção inválida foi detectada. |
| 22 | Ocorreu um erro de biblioteca criptográfica. |
| 23 | Foi feita uma chamada inválida de dentro do DllMain. |
| 24 | Um endereço de base de imagem inválido foi detectado. |
| 25 | Foi encontrada uma falha irrecuperável ao proteger uma importação de carga atrasada. |
| 26 | Uma chamada foi feita para uma extensão não segura. |
| 27 | Um serviço obsoleto foi invocado. |
| 28 | Um acesso ao buffer fora dos limites foi detectado. |
| 29 | Uma entrada RTL_BALANCED_NODE RBTree foi corrompida. |
| 37 | Uma entrada que pode ser pulada de alternância fora do intervalo foi invocada. |
| 38 | Um longjmp foi tentado para um destino inválido. |
| 39 | Não foi possível transformar um destino de chamada suprimido de exportação em um destino de chamada válido. |
Causa
Ao usar a tabela do parâmetro 1 e um arquivo de despejo, é possível restringir a causa de muitas verificações de bugs desse tipo.
A corrupção LIST_ENTRY pode ser difícil de rastrear e essa verificação de bugs indica que uma inconsistência foi introduzida em uma lista duplamente vinculada (detectada quando um elemento de entrada de lista individual é adicionado ou removido da lista). Infelizmente, a inconsistência não é necessariamente detectada no momento em que a corrupção ocorreu, portanto, pode ser necessário algum trabalho de detecção para identificar a causa raiz.
As causas comuns de corrupção de entrada de lista incluem:
- Um driver corrompeu um objeto de sincronização do kernel, como um KEVENT (por exemplo, inicializando duas vezes um KEVENT enquanto um thread ainda estava esperando no mesmo KEVENT ou permitindo que um KEVENT baseado em pilha saísse do escopo enquanto outro thread estava usando esse KEVENT). Esse tipo de verificação de bugs geralmente ocorre no código nt!Ke* ou nt!Ki*. Isso pode acontecer quando um thread termina de aguardar um objeto de sincronização ou quando o código tenta colocar um objeto de sincronização no estado sinalizado. Normalmente, o objeto de sincronização que está sendo sinalizado é aquele que foi corrompido. Às vezes, o verificador de driver com pool especial pode ajudar a rastrear o culpado (se o objeto de sincronização corrompido estiver em um bloco de pool que já foi liberado).
- Um driver corrompeu um KTIMER periódico. Esse tipo de verificação de bugs normalmente ocorre em nt! Ke * ou nt! Ki* e envolve a sinalização de um cronômetro ou a inserção ou remoção de um cronômetro de uma tabela de cronômetro. O temporizador que está sendo manipulado pode ser o corrompido, mas pode ser necessário inspecionar a tabela de temporizadores com !timer (ou percorrer manualmente os links da lista de temporizadores) para identificar qual temporizador foi corrompido. Às vezes, o verificador de driver com pool especial pode ajudar a rastrear o culpado (se o KTIMER corrompido estiver em um bloco de pool que já tenha sido liberado).
- Um driver administrou mal uma lista vinculada interna no estilo LIST_ENTRY. Um exemplo típico seria chamar RemoveEntryList duas vezes na mesma entrada de lista sem reinserir a entrada de lista entre as duas chamadas RemoveEntryList. Outras variações são possíveis, como inserir duas vezes uma entrada na mesma lista.
- Um driver liberou uma estrutura de dados que contém um LIST_ENTRY sem remover a estrutura de dados de sua lista correspondente, fazendo com que a corrupção seja detectada posteriormente quando a lista for examinada depois que o antigo bloco de pool for reutilizado.
- Um driver usou uma lista do tipo LIST_ENTRY de forma simultânea sem a sincronização adequada, resultando em uma atualização interrompida da lista.
Na maioria dos casos, você pode identificar a estrutura de dados corrompida percorrendo a lista vinculada para frente e para trás (os comandos dl e dlb são úteis para essa finalidade) e comparando os resultados. O ponto em que a lista é inconsistente entre uma percorrida para frente e para trás é, normalmente, o local da corrupção. Como uma operação de atualização de lista vinculada pode modificar os links de lista de um elemento vizinho, você deve observar atentamente os vizinhos de uma entrada de lista corrompida, pois eles podem ser os culpados subjacentes.
Como muitos componentes do sistema utilizam internamente as listas LIST_ENTRY, vários tipos de mau gerenciamento de recursos por um driver que usa APIs do sistema podem causar corrupção de lista vinculada em uma lista vinculada gerenciada pelo sistema.
Resolução
Determinar a causa desses problemas normalmente requer o uso do depurador para coletar informações adicionais. Vários arquivos de despejo devem ser examinados para ver se esse código de parada tem características semelhantes, como o código que está sendo executado quando o código de parada aparece.
Para obter mais informações, consulte Análise de despejo de memória usando os depuradores do Windows (WinDbg), usando a extensão !analyze e !analyze.
Use o log de eventos para ver se há eventos de nível superior que ocorrem antes desse código de parada.
Essas dicas gerais de solução de problemas podem ser úteis.
Se você adicionou hardware ao sistema recentemente, tente removê-lo ou substituí-lo. Ou verifique com o fabricante se há patches disponíveis.
Se você instalou novos drivers de dispositivo ou serviços do sistema recentemente, tente removê-los ou atualizá-los. Tente determinar o que mudou no sistema que causou o aparecimento do novo código de verificação de bugs.
Verifique o log do sistema no visualizador de eventos para obter mensagens de erro adicionais que possam ajudar a identificar o dispositivo ou driver que está causando o erro. Para mais informações, consulte Abrir o Visualizador de Eventos.. Procure erros críticos no log do sistema que ocorreram na mesma janela de tempo que a tela azul.
Procure em Gerenciador de Dispositivos para ver se algum dispositivo está marcado com o ponto de exclamação (!). Revise o log de eventos exibido nas propriedades do driver para qualquer driver com falha. Tente atualizar o driver relacionado.
Execute um programa de detecção de vírus. Os vírus podem infectar todos os tipos de discos rígidos formatados para Windows, e a corrupção do disco resultante pode gerar códigos de verificação de bugs no sistema. Certifique-se de que o programa de detecção de vírus verifique se há infecções no registro mestre de inicialização.
Para obter mais informações gerais sobre solução de problemas, consulte Analisar dados de tela azul de verificação de bugs.
Consulte também
Análise de despejo de memória usando os depuradores do Windows (WinDbg)
Analisando um arquivo de despejo no modo kernel com o WinDbg