Compartilhar via

Verificação de bugs 0x139: KERNEL_SECURITY_CHECK_FAILURE

A verificação de bugs KERNEL_SECURITY_CHECK_FAILURE tem um valor de 0x00000139 e indica que o kernel detecta a corrupção de uma estrutura de dados crítica.

Importante

Este artigo é para programadores. Se você for um cliente que recebe um código de erro de tela azul ao usar seu 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, consulte a tabela seguinte.
2 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 Reservado

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 é invadido (violação herdada /GS).
1 O código de instrumentação VTGuard detectou uma tentativa de usar uma tabela de funções virtual ilegal. Normalmente, um objeto C++ está corrompido e, em seguida, uma chamada de método virtual tentou usar esse ponteiro do objeto corrompido.
2 O código de instrumentação de cookie de pilha detectou uma saturação de buffer baseada em pilha (violação de /GS).
3 Um LIST_ENTRY está corrompido (por exemplo, uma remoção dupla). Para obter mais informações, consulte a seção Causa a seguir.
4 Reservado
5 Um parâmetro inválido foi passado para uma função que considera parâmetros inválidos fatais.
6 O carregador não inicializou corretamente o cookie de segurança do cookie de pilha. Essa verificação de bugs é causada pela criação de um driver para execução somente no Windows 8 e a tentativa de carregar a imagem do driver em uma versão anterior do Windows. Para evitar o 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 de indexação de matriz ilegal.
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 indireta do protetor de chamada detectou transferência de controle inválida.
11 A verificação de proteção contra gravação detectou gravação de memória inválida.
12 Foi feita uma tentativa de mudar 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 mudar para um contexto de 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 Uma chamada inválida foi feita de dentro de DllMain.
24 Um endereço base de imagem inválido foi detectado.
25 Uma falha irrecuperável foi encontrada ao proteger uma importação de carga atrasada.
26 Foi feita uma ligação para um ramal inseguro.
27 Um serviço preterido foi invocado.
28 Um acesso ao buffer fora dos limites foi detectado.
29 Uma entrada RTL_BALANCED_NODE RBTree está corrompida.
37 Uma entrada de jumptable de switch fora do alcance foi invocada.
38 Um longjmp foi tentado para um alvo inválido.
39 Um destino de chamada suprimido de exportação não pôde ser transformado em um destino de chamada válido.

Motivo

Usando a tabela de parâmetro 1 e um arquivo de despejo, você pode restringir a causa de muitas verificações de bugs desse tipo.

LIST_ENTRY corrupção pode ser difícil de rastrear. Essa verificação de bug 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, algum trabalho de detetive pode ser necessário para identificar a causa raiz.

As causas comuns de corrupção de entrada de lista incluem:

  • Um driver corrompia um objeto de sincronização de 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 bug normalmente ocorre em nt! Ke * ou nt! Código 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 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 já liberado).
  • Um driver corrompeu um KTIMER periódico. Esse tipo de verificação de bug 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 temporizador com !timer (ou percorrer manualmente os links da lista de temporizadores) para identificar qual temporizador está 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á está liberado).
  • Um driver gerenciou mal uma lista vinculada no estilo LIST_ENTRY interno. 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 de reutilizando o bloco de pool antigo.
  • Um driver usou uma lista de estilos de LIST_ENTRY de forma simultânea sem sincronização adequada, resultando em uma atualização rasgada para a 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. Onde a lista é inconsistente entre uma caminhada 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 examinar os vizinhos de uma entrada de lista corrompida de perto, pois eles podem ser os culpados subjacentes.

Como muitos componentes do sistema utilizam internamente listas LIST_ENTRY, vários tipos de gerenciamento incorreto de recursos por um driver usando APIs do sistema podem causar corrupção de lista vinculada em uma lista vinculada gerenciada pelo sistema.

Resolução

Determinar a causa de problemas de corrupção de entrada de lista normalmente requer o uso do depurador para coletar outras informações. Vários arquivos de despejo devem ser examinados para ver se o código de parada tem características semelhantes, como o código em execução quando o código de parada é exibido.

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 do 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 foi alterado no sistema que fez com que o novo código de verificação de bugs aparecesse.

  • Verifique no Visualizador de Eventos do Log do Sistema outras mensagens de erro que podem ajudar a identificar o dispositivo ou driver que está causando o erro. Procure erros críticos no log do sistema que ocorreram na mesma janela de tempo que a tela azul.

  • Procure no Gerenciador de dispositivos para ver se algum dispositivo está marcado com o ponto de exclamação (!). Examine 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 de disco resultante pode gerar códigos de verificação de bugs do 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 de 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 de Kernel-Mode com o WinDbg

  • Last updated on