Base de conhecimento →6 min de leituraAtualizado: 2026-09-21

Como corrigir o KERNEL SECURITY CHECK FAILURE no Windows 11

O erro KERNEL_SECURITY_CHECK_FAILURE, código de parada 0x00000139, é levantado pelo próprio Windows quando uma estrutura da qual o kernel depende reprova numa checagem interna de consistência — o sistema pegou a própria contabilidade corrompida e se recusou a seguir em cima dela. O nome soa dramático, mas as causas são banais: memória instável em primeiro, driver com bug corrompendo dados do kernel em segundo, arquivos do sistema danificados em terceiro. Seguindo exatamente essa ordem — memória, arquivos, drivers — dá pra limpar a grande maioria das máquinas.

O que reprova na checagem de segurança

O kernel mantém somas de verificação e invariantes sobre suas estruturas críticas, mais ou menos como um banco que concilia os livros várias vezes por segundo. O código 0x139 significa que uma dessas conciliações saiu errada: um ponteiro de lista não aponta mais para onde deve, ou o cabeçalho de um buffer não corresponde mais ao conteúdo dele. O Windows para de propósito, porque continuar com o estado do kernel corrompido arrisca escrever lixo pelo disco inteiro.

O que corrompe essas estruturas raramente é mistério. Memória que devolve bits invertidos sob carga — muitas vezes um perfil XMP ou EXPO além do que o controlador de memória aguenta de verdade — lidera a lista. Drivers que escrevem fora dos buffers vêm em seguida, com os de GPU e antivírus como reincidentes. Arquivos do sistema danificados e um SSD morrendo que entrega leituras corrompidas completam o quadro.

  • RAM instável — perfis XMP/EXPO além do que o controlador de memória da CPU aguenta de verdade
  • Driver com bug escrevendo fora do buffer — GPU, antivírus e virtualização são os reincidentes
  • Arquivos do sistema corrompidos por uma atualização que falhou ou um corte de energia repentino
  • SSD moribundo que devolve dados corrompidos na leitura, visível nos atributos SMART
  • Undervolt ou overclock agressivos virando bits sob carga

Testar a memória e reparar os arquivos

Comece pela memória: é a causa mais comum e a mais barata de eliminar. Rode o mdsched.exe, reinicie quando ele pedir e deixe a passada padrão correr; o veredito aparece no Visualizador de Eventos, em Registros do Windows → Sistema, origem MemoryDiagnostics-Results. A passada padrão só pega falhas grosseiras — se os travamentos continuam com resultado limpo, desligue o XMP/EXPO na BIOS e teste os pentes um a um antes de dar à memória um atestado de inocência.

Os arquivos vêm depois, num “Prompt de Comando (Administrador)”: sfc /scannow confere os arquivos protegidos com o repositório de componentes, depois DISM /Online /Cleanup-Image /RestoreHealth conserta o próprio repositório se o SFC não deu conta de tudo, e depois chkdsk C: /f /r varre a superfície do disco no próximo reinício. Uma reinstalação limpa do driver de vídeo fecha a parte de software: baixe o pacote mais novo, remova o antigo em Configurações → Aplicativos → Aplicativos instalados e instale o novo após reiniciar.

Encurralar o reincidente

Se o código de parada sobrevive a tudo isso, o travamento já é específico o bastante para ter nome. Os minidumps de C:\Windows\Minidump carregam o endereço da falha e a lista de módulos carregados; o WinDbg com !analyze -v ou um leitor como o BlueScreenView transforma isso num nome de driver, e esse nome encerra a caça. Ao software instalado nos dias anteriores ao primeiro travamento cabe o primeiro interrogatório: desinstalá-lo é teste e tratamento ao mesmo tempo.

A ferramenta de último recurso é o Verificador de Driver (verifier /standard /all num console de administrador), que faz drivers suspeitos estourar nos próprios bugs, barulhentamente e na hora. Ela é perigosa de propósito: conte com telas azuis enquanto estiver ativa e grave a saída — dê boot no Modo Seguro e rode verifier /reset para desligá-la. Conduzida assim, o Verifier defuma um driver escondido num ou dois dias.

Perguntas e respostas

KERNEL_SECURITY_CHECK_FAILURE é sinal de malware?

Raramente. A checagem pega corrupção, não infecção, e as causas são esmagadoramente hardware e drivers. Um rootkit corruptor é possível, mas lá embaixo na lista.

RAM com defeito pode causar KERNEL_SECURITY_CHECK_FAILURE?

Pode — é a causa isolada mais comum. Rode o mdsched.exe, desligue o XMP/EXPO e teste os pentes um a um se os travamentos não pararem.

Como parar o KERNEL SECURITY CHECK FAILURE na inicialização?

Dê boot no Modo Seguro pelo WinRE (Configurações de Inicialização → tecla 4), desinstale o que chegou por último e rode SFC e DISM de lá — o travamento raramente te segue.

Veja exatamente o que está incluído antes de comprar.

O teste único de 30 minutos cobre os recursos básicos. Os recursos marcados PRO ficam bloqueados até a ativação de uma licença paga.

Continue lendo

Todos os artigos · FAQ

Fale com a gente: [email protected]