Você estava trabalhando normalmente, talvez editando uma planilha ou assistindo a uma aula, quando a tela ficou completamente azul com a mensagem KERNEL_SECURITY_CHECK_FAILURE e um código começando com 0x139. O computador reiniciou sozinho e você ficou sem saber o que aconteceu. Parece catastrófico, mas o erro kernel_security_check_failure tem causa identificável e correção acessível.
Neste artigo você vai entender o que esse bug check representa, por que ele aparece no Windows 10 e 11, e como executar um diagnóstico antes de sair aplicando correções às cegas. Ao final, você terá um caminho claro: verificar a memória, analisar logs, reparar arquivos do sistema, atualizar ou reverter drivers e, se necessário, acessar o ambiente de recuperação para consertar o Windows sem perder seus dados.
O que é o erro KERNEL_SECURITY_CHECK_FAILURE (0x139) e por que ele aparece
O que o código 0x139 representa
O bug check 0x00000139 é acionado quando o kernel do Windows detecta corrupção em estruturas críticas de dados, como listas encadeadas internas ou objetos de sincronização. O sistema para propositalmente para evitar danos maiores: é um mecanismo de proteção, não uma falha aleatória. Sem essa parada forçada, a corrupção poderia se propagar e tornar a recuperação impossível.
Para quem quer ir fundo no diagnóstico, o parâmetro 1 do erro (visível no arquivo de dump de memória) indica o subtipo exato da corrupção. O valor 3, por exemplo, aponta para corrupção de LIST_ENTRY; o valor 5 indica parâmetros inválidos em chamadas do kernel. Ferramentas como o WinDbg conseguem extrair esse detalhe, mas para a maioria dos casos o fluxo de diagnóstico descrito aqui já é suficiente. Consulte a documentação da Microsoft sobre o bug check 0x139 para referência técnica detalhada.
Por que o Windows 10 e 11 registram esse erro com frequência
Atualizações frequentes do sistema operacional combinadas com a enorme variedade de hardware no mercado brasileiro criam um ambiente propício para incompatibilidades. Relatórios de crash e discussões em fóruns técnicos mostram que o BSOD 0x139 aparece especialmente em dois cenários: máquinas montadas com peças de diferentes gerações, nas quais drivers de fabricantes mais antigos deixaram de receber suporte, e sistemas com Windows Update ativo, onde uma atualização automática pode substituir um driver que estava funcionando bem.
Um exemplo típico é uma atualização do Windows que quebra o driver de vídeo da NVIDIA ou AMD. Outro é um SSD novo instalado sem atualização de firmware, ou ainda um software de terceiros que modifica arquivos protegidos do núcleo do sistema. São cenários plausíveis e amplamente relatados em comunidades técnicas, não casos isolados. Identificar qual dessas situações se aplica ao seu caso é o primeiro passo antes de qualquer correção.
As três causas mais comuns da tela azul 0x139
Drivers incompatíveis ou desatualizados
Drivers figuram entre as causas mais frequentemente reportadas em dumps de crash associados ao kernel_security_check_failure. Os de GPU, especialmente o arquivo nvlddmkm.sys da NVIDIA, aparecem com destaque nesses registros, assim como drivers de armazenamento como storport.sys. O mecanismo é direto: o driver corrompeu um objeto de sincronização ou uma lista interna do kernel, e o Windows detectou isso na verificação de segurança. Se o BSOD começou logo após uma atualização de driver ou do próprio Windows, essa correlação temporal é o dado mais valioso que você tem na hora do diagnóstico, e já indica por onde começar.
Memória RAM com defeito
Módulos de RAM com falha causam corrupção de dados em memória, que o kernel detecta durante operações normais. Esse tipo de problema é traiçoeiro porque aparece de forma intermitente: o computador pode funcionar bem por horas e travar de surpresa, dificultando a reprodução do erro. Overclocking de memória com perfis XMP ou EXPO mal configurados também provoca instabilidade e aciona o kernel_security_check_failure com frequência, fabricantes de placas-mãe como ASUS e MSI documentam em seus guias de XMP que perfis agressivos exigem validação com ferramentas como o MemTest86 antes de serem considerados estáveis.
Malware e arquivos do sistema corrompidos
Infecções que modificam arquivos do núcleo do sistema ou provocam buffer overflow disparam a verificação de segurança do kernel. Arquivos corrompidos por desligamento forçado durante uma atualização ou falha em disco entram na mesma categoria. Antes de aplicar qualquer correção, vale identificar qual dessas origens é a mais provável no seu caso, isso poupa tempo e evita passos desnecessários.
Diagnóstico do kernel_security_check_failure: como identificar a causa antes de corrigir
Verificar a memória RAM com o Windows Memory Diagnostic
Pressione Win + R, digite mdsched.exe e escolha reiniciar agora para verificar. O processo é automatizado e roda antes do Windows carregar. Após a reinicialização, os resultados aparecem na área de notificação; para ver o relatório completo, abra o Visualizador de Eventos, vá em Logs do Windows, depois Sistema, e filtre por “MemoryDiagnostics-Results”, a documentação da Microsoft detalha esse processo na base de conhecimento de suporte ao consumidor.
O Windows Memory Diagnostic é um bom ponto de partida, mas tem limitações para erros intermitentes. Para uma confirmação mais robusta, use o MemTest86: bootável por pendrive, ele roda fora do Windows e testa a RAM com dezenas de algoritmos diferentes. Execute pelo menos três passes completos, conforme recomendado na documentação oficial do MemTest86; dependendo da quantidade de memória instalada, isso pode levar algumas horas.
Erros marcados em vermelho ao final dos passes confirmam falha física no módulo e justificam a substituição imediata, antes de qualquer outro passo de software.
Analisar logs e o arquivo de dump de memória
Abra o Visualizador de Eventos com Win + R e o comando eventvwr, depois filtre erros críticos no horário exato do BSOD. Isso já indica o contexto do problema. Para ir além, use o BlueScreenView da NirSoft: ele lê os minidumps armazenados em C:\Windows\Minidump e exibe, na parte inferior da tela, os drivers que estavam ativos no momento da falha, destacando em vermelho os mais prováveis causadores. Vale lembrar que o destaque em vermelho é uma indicação, não uma certeza absoluta, confirme cruzando com a correlação temporal do BSOD.
O nome do arquivo .sys indicado no dump direciona diretamente o próximo passo. Se aparecer nvlddmkm.sys, o foco é no driver de vídeo NVIDIA. Se aparecer storport.sys, investigue os drivers de armazenamento. Essa informação transforma um problema genérico em uma correção específica.
Como corrigir o kernel_security_check_failure: arquivos do sistema e drivers
Reparar o Windows com DISM e SFC
A ordem correta importa: execute o DISM primeiro para reparar a imagem do sistema, depois o SFC para corrigir arquivos individuais corrompidos. Abra o Prompt de Comando como administrador e execute os seguintes comandos, um de cada vez:
DISM /Online /Cleanup-Image /CheckHealthDISM /Online /Cleanup-Image /ScanHealthDISM /Online /Cleanup-Image /RestoreHealthsfc /scannow
O processo pode levar alguns minutos. Reinicie o computador após os comandos e observe se o BSOD retorna. Se o SFC indicar que não conseguiu corrigir alguns arquivos, repita o DISM com RestoreHealth antes de rodar o SFC novamente. Para um passo a passo detalhado sobre o uso de DISM e SFC, veja nosso guia prático de SFC e DISM.
Atualizar ou reverter drivers no Modo de Segurança
Para acessar o Modo de Segurança, pressione Shift enquanto clica em Reiniciar na tela de login, depois vá em Solucionar problemas, Opções avançadas, Configurações de inicialização e escolha a opção 4 ou 5. No Modo de Segurança, apenas drivers essenciais carregam, o que permite trabalhar com mais estabilidade.
No Gerenciador de Dispositivos, expanda Adaptadores de vídeo e Unidades de disco. Procure ícones com ponto de exclamação amarelo. Para cada driver suspeito: botão direito, Propriedades, aba Driver. Se o botão “Reverter Driver” estiver disponível, use-o primeiro; caso contrário, baixe a versão mais recente diretamente do site do fabricante (NVIDIA, AMD, Intel ou fabricante da placa-mãe) e instale. A Restauração do Sistema, acessível pelo comando rstrui, é uma alternativa rápida se o BSOD começou em uma data específica que você consegue identificar.
Quando o Windows não inicia mais: reparação de arranque
Acessar o ambiente de recuperação (WinRE) e reparar o disco
Se o sistema entrou em loop de tela azul e não inicia normalmente, você tem dois caminhos para chegar ao ambiente de recuperação do Windows: forçar 3 ou 4 desligamentos durante o boot (o Windows detecta a sequência e abre o WinRE automaticamente), ou usar um pendrive de instalação criado pela Media Creation Tool da Microsoft em outro computador. Com o pendrive, selecione “Reparar seu computador” na tela inicial do instalador.
No WinRE, vá em Solucionar problemas, Opções avançadas e abra o Prompt de Comando. Execute o CHKDSK para verificar e corrigir erros no sistema de arquivos NTFS: chkdsk C: /f /r. Em seguida, rode o SFC no modo offline: sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows. Esses comandos tratam corrupções que não são acessíveis com o Windows em execução. Se quiser entender melhor a diferença entre chkdsk /f e chkdsk /r antes de rodar, essa referência explica o que cada parâmetro faz.
Restauração do sistema e atualização no local como último recurso
Pelo WinRE, tente a Restauração do Sistema selecionando um ponto anterior ao início dos problemas. Se não houver pontos de restauração ou eles não resolverem, a atualização no local (in-place upgrade) com o ISO do Windows reinstala o sistema por cima, mantendo seus arquivos e aplicativos instalados. Antes de qualquer reinstalação, faça backup dos dados via Prompt de Comando com o comando xcopy C:\Users D:\Backup /E /H, substituindo D:\Backup pelo destino desejado. Para procedimentos completos de recuperação e preservação de dados, consulte também o artigo Como Corrigir Erros Críticos do Windows Sem Perder Dados.
Se o BSOD persistir após todos esses passos, o diagnóstico mais provável aponta para hardware defeituoso: disco ou RAM com falha física. Nesse caso, o caminho é substituir o componente ou buscar suporte técnico presencial.
Como evitar que erros como esse travem sua rotina
Manutenção preventiva que faz diferença
Manter o Windows e os drivers atualizados reduz riscos, mas vale uma ressalva: antes de instalar uma atualização de driver de vídeo nova em um PC de trabalho, consulte fóruns para verificar se outros usuários relataram problemas. Nem toda atualização recente é estável. Além disso, mantenha um antivírus ativo, faça varreduras periódicas, e nunca force o desligamento durante atualizações em andamento.
- Atualize drivers com atenção ao histórico de versões, especialmente GPU e chipset.
- Evite overclocking de memória sem teste de estabilidade com MemTest86 antes.
- Configure pontos de restauração automáticos para ter sempre uma saída rápida.
Por que aprender informática de forma estruturada muda o jogo
Saber diagnosticar um kernel_security_check_failure, entender o que é um driver e navegar no Modo de Segurança não são habilidades exclusivas de técnicos de informática. São competências práticas que qualquer profissional conectado consegue desenvolver com o método certo. Ainda assim, muita gente chega até aqui, segue os passos corretamente e, na próxima tela azul, volta à estaca zero, porque faltou o contexto que liga um passo ao outro.
É para preencher exatamente essa lacuna que o Professor Diogo Puiatti estruturou seus cursos de informática: aulas em vídeo com passo a passo comentado, materiais para download e atendimento direto, desenvolvidos para o contexto do usuário brasileiro. Não é teoria abstrata; é o tipo de conhecimento aplicado que você usa no dia seguinte ao aprender. Para mais conteúdos sobre Erros no Windows e como resolvê-los, visite a página com guias e tutoriais práticos.
Conclusão
A tela azul kernel_security_check_failure é assustadora na primeira vez que aparece, mas tem causa identificável e correção acessível. O segredo está na sequência lógica: diagnosticar primeiro (memória, logs, dumps), depois corrigir (SFC/DISM, drivers, WinRE). Pular etapas leva a correções desnecessárias e perda de tempo.
Seguir essa sequência diagnóstico-primeiro resolve a maioria dos casos de kernel_security_check_failure sem formatação e sem técnico. Com os passos descritos aqui, você tem tudo que precisa para retomar o controle do próprio computador, e, na próxima vez que a tela azul aparecer, já vai saber exatamente por onde começar.


Deixe um comentário