Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O KERNEL_SECURITY_CHECK_FAILURE bug check tem um valor de 0x00000139 e indica que o kernel deteta a corrupção de uma estrutura de dados crítica.
Importante
Este artigo é para programadores. Se é um cliente que recebe um código de erro de ecrã azul enquanto usa o computador, veja Resolver erros de ecrã 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 a seguir. |
2 |
Endereço do quadro de trap para a exceção que causou a verificação de bug |
3 |
Endereço do registro de exceção para a exceção que causou a verificação de bug |
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 stack é ultrapassado (violação legada /GS). |
1 |
O código de instrumentação VTGuard detetou uma tentativa de usar uma tabela de funções virtuais ilegal. Normalmente, um objeto C++ é corrompido, e depois uma chamada de método virtual tenta usar o ponteiro this do objeto corrompido. |
2 |
O código de instrumentação de cookie de pilha detetou uma saturação de buffer baseada em pilha (violação /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 dos cookies da pilha. Esta verificação de bugs pode ser causada por construir um driver para correr apenas no Windows 8 e tentar carregar a imagem do driver numa versão anterior do Windows. Para evitar o problema, deve construir o driver para correr numa versão anterior do Windows. |
7 |
Foi solicitada uma saída fatal do programa. |
8 |
Uma verificação de limites de array inserida pelo compilador detetou uma operação ilegal de indexação de array. |
9 |
Foi feita uma chamada ao RtlQueryRegistryValues especificando RTL_QUERY_REGISTRY_DIRECT sem RTL_QUERY_REGISTRY_TYPECHECK, e o valor alvo não estava numa colmeia de sistema confiável. |
10 |
A verificação indireta do protetor de chamadas detetou uma transferência de controle inválida. |
11 |
A verificação de proteção de gravação detetou 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 registo 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 |
Foi feita uma modificação insegura nos dados somente leitura. |
20 |
Um autoteste criptográfico falhou. |
21 |
Foi detetada uma cadeia de exceção inválida. |
22 |
Ocorreu um erro de biblioteca criptográfica. |
23 |
Uma chamada inválida foi feita de dentro DllMain. |
24 |
Foi detetado um endereço base de imagem inválido. |
25 |
Foi encontrada uma falha irrecuperável ao proteger uma importação de carga de atraso. |
26 |
Foi feita uma chamada para uma extensão insegura. |
27 |
Um serviço preterido foi invocado. |
28 |
Foi detetado um acesso de buffer fora dos limites. |
29 |
Uma RTL_BALANCED_NODE entrada RBTree está corrompida. |
37 |
Foi invocada uma entrada jumptable de interruptor fora do alcance. |
38 |
Um longjmp foi tentado para um alvo inválido. |
39 |
Não foi possível tornar um destino de chamada suprimido de exportação um destino de chamada válido. |
Motivo
Usando a tabela do parâmetro 1 e um ficheiro de dump, pode restringir a causa de muitas verificações de bugs deste tipo.
LIST_ENTRY corrupção pode ser difícil de localizar. Esta verificação de bugs indica que uma inconsistência foi introduzida numa lista duplamente ligada (detetada quando um elemento individual de entrada da lista é adicionado ou removido da lista). Infelizmente, a inconsistência não é necessariamente detetada no momento em que a corrupção ocorreu, então algum trabalho de detetive pode ser necessário para identificar a causa raiz.
As causas comuns de corrupção de entradas de lista incluem:
- Um driver corrompeu um objeto de sincronização do kernel, como um KEVENT (por exemplo, inicializar dupla um KEVENT enquanto um thread ainda estava à espera desse mesmo KEVENT, ou permitir que um KEVENT baseado em stack saísse do âmbito enquanto outro thread estava a usar esse KEVENT). Este tipo de verificação de bug normalmente ocorre em nt! Ke* ou nt! Código Ki*. Isso pode acontecer quando um thread termina de esperar em 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á a ser sinalizado é o que está corrompido. Por vezes, o Driver Verifier com pool especial pode ajudar a localizar o culpado (se o objeto de sincronização corrompido estiver num bloco de pool que já foi libertado).
- Um driver corrompeu um KTIMER periódico. Este tipo de verificação de bug normalmente ocorre em nt! Ke* ou nt! Ki* e envolve a sinalização de um temporizador ou a inserção ou remoção de um temporizador de uma tabela de temporizadores. O temporizador 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 dos temporizadores está corrompido. Por vezes, o Driver Verifier com pool especial pode ajudar a localizar o culpado (se o KTIMER corrompido estiver num bloco de pool que já foi libertado).
- Um condutor geriu mal uma lista interna ligada ao 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 . São possíveis outras variações, como a dupla inserção de uma entrada na mesma lista.
- Um driver libertou uma estrutura de dados que contém um LIST_ENTRY sem remover a estrutura de dados da sua lista correspondente, causando a deteção de corrupção mais tarde quando a lista é examinada após a reutilização do bloco antigo do pool.
- Um driver usava uma lista ao estilo LIST_ENTRY de forma simultânea, sem sincronização adequada, resultando numa atualização rasgada da lista.
Na maioria dos casos, você pode identificar a estrutura de dados corrompida andando 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 um andar para frente e para trás é tipicamente 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 de LIST_ENTRY, vários tipos de gerenciamento indevido 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 dos problemas de corrupção na entrada de listas normalmente requer o uso do depurador para recolher outras informações. Devem ser analisados vários ficheiros de dump para ver se o código de parada tem características semelhantes, como o código que está a correr 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 registo de eventos para ver se há eventos de nível superior que conduzem ao código de paragem.
Estas dicas gerais de solução de problemas podem ser úteis.
Se adicionou recentemente hardware ao sistema, tente removê-lo ou substituí-lo. Ou verifique com o fabricante se existem patches disponíveis.
Se novos drivers de dispositivo ou serviços do sistema tiverem sido adicionados recentemente, tente removê-los ou atualizá-los. Tente determinar o que mudou no sistema que fez com que o novo código de verificação de bug aparecesse.
Verifique o Visualizador de Eventos de Login do Sistema para outras mensagens de erro que possam ajudar a identificar o dispositivo ou driver que está a causar o erro. Procure erros críticos no log do sistema que ocorreram na mesma janela de tempo da tela azul.
Procure no Gestor 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 verificar se há um driver com falha. Tente atualizar o driver relacionado.
Execute um programa de deteção de vírus. Os vírus podem infetar 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 deteção de vírus verifica se há infeções no Master Boot Record.
Para informações mais gerais sobre resolução de problemas, consulte Analisar Dados do Ecrã Azul da Verificação de Bugs.
Ver 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