Verificação de bugs 0x139: KERNEL_SECURITY_CHECK_FAILURE

A verificação de bug 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 ao usar o computador, consulte 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 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 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 foi 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 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.
oito	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 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.
vinte e três	Uma chamada inválida foi feita de dentro de DllMain.
24	Um endereço base de imagem inválido foi detectado.
vinte e cinco	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 foi 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âmetros 1 e um arquivo de despejo, é possível restringir a causa de muitas verificações de bugs desse tipo.

LIST_ENTRY corrupção pode ser difícil de rastrear e 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 corrompeu um objeto de sincronização de kernel, como um KEVENT (por exemplo, inicializando duas vezes um KEVENT enquanto um thread ainda estava aguardando o 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 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 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 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á foi 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 após o bloco de pool antigo ter sido reutilizado.
• Um driver usou uma lista de estilo LIST_ENTRY de forma simultânea sem sincronização adequada, resultando em uma atualização interrompida na 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 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á em execução 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 foi alterado no sistema que fez com que o novo código de verificação de bugs aparecesse.

• 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. 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 informações gerais adicionais 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 de Kernel-Mode com o WinDbg