O computador trava do nada, a tela fica azul e aparece aquele texto assustador: IRQL_NOT_LESS_OR_EQUAL. Para a maioria das pessoas, esse momento gera pânico imediato. A primeira reação costuma ser ligar para alguém ou cogitar formatar tudo. Respira fundo: esse não é o caminho certo.
Esse erro tem uma causa identificável e, na maior parte dos casos, tem solução sem precisar reinstalar o Windows. O sistema operacional deixa rastros precisos sobre o que aconteceu, e com as ferramentas certas você chega à origem do problema em menos de uma hora. Neste guia você vai aprender a identificar o driver ou componente responsável pelo crash, aplicar as correções na ordem correta e reconhecer quando o problema está no hardware físico.
O que significa esse código de erro e por que o Windows trava
O Windows usa a tela azul como mecanismo de proteção. Quando algo tenta danificar a memória do núcleo do sistema, o próprio sistema operacional prefere parar completamente do que deixar a corrupção acontecer. Esse comportamento é intencional e, no fundo, é um bom sinal: o sistema identificou o problema antes que causasse danos irreversíveis.
O STOP code 0xA, tecnicamente chamado de DRIVER IRQL NOT LESS OR EQUAL, ocorre quando um processo em modo kernel tenta acessar um endereço de memória inválido ou sem permissão. Pense nisso como uma placa de “acesso proibido”: o processo tentou entrar em uma área que não era dele, e o Windows bloqueou a tentativa imediatamente.
O termo IRQL significa Interrupt Request Level, uma fila de prioridades que o Windows usa para gerenciar quem acessa a memória e em qual momento. Drivers precisam respeitar esse nível. Quando um driver mal escrito ou corrompido viola essa regra, o bug check 0xA é disparado. O resultado prático é o travamento, mas esse travamento deixa um arquivo de diagnóstico que você pode analisar para encontrar a causa.
Por que o erro IRQL NOT LESS OR EQUAL aparece no seu computador
Drivers incompatíveis ou desatualizados são a causa mais frequente do IRQL_NOT_LESS_OR_EQUAL. Drivers de placa de vídeo da NVIDIA e AMD, controladores de rede e drivers de SSD NVMe figuram entre os suspeitos mais comuns em análises de crash dumps. Uma atualização recente do Windows ou a instalação de um novo driver costuma anteceder o primeiro crash: se o erro começou logo após instalar algo novo, o culpado provavelmente está ali.
Módulos de RAM defeituosos ou mal encaixados também geram exatamente esse tipo de tela azul. Quando a memória apresenta falhas, o sistema tenta acessar endereços inválidos e o erro IRQL é disparado como consequência direta. Superaquecimento, discos com setores defeituosos e periféricos USB com drivers problemáticos entram na mesma lista de suspeitos.
Arquivos de sistema corrompidos completam o quadro. Quedas de energia durante atualizações, vírus ou interrupções no processo de instalação do Windows podem deixar arquivos essenciais danificados. Esses arquivos corrompidos interferem no funcionamento dos drivers e reproduzem o mesmo comportamento de crash.
Como identificar o driver que causou o IRQL_NOT_LESS_OR_EQUAL
Após um BSOD, o Windows salva automaticamente um arquivo de diagnóstico em C:\Windows\Minidump. Para garantir que esse recurso está ativo, acesse Propriedades do Sistema, clique em “Inicialização e Recuperação” e depois em “Configurações”. No campo “Gravar informações de depuração”, selecione “Dump de memória pequeno (256 KB)”. Sem minidumps habilitados, o diagnóstico fica muito mais difícil e menos preciso.
Com o arquivo .dmp em mãos, o WhoCrashed é a opção mais acessível para usuários comuns. Basta instalar, clicar em “Analisar” e o programa exibe diretamente o nome do driver responsável, algo como nvlddmkm.sys para drivers NVIDIA. Para análises mais detalhadas, o WinDbg com o comando !analyze -v mostra o stack completo do kernel e aponta o módulo no topo da pilha de chamadas.
A regra prática é simples: se múltiplos dumps apontam para o mesmo arquivo .sys, o diagnóstico está confirmado e todo o foco vai para aquele driver específico. Arquivos como ntoskrnl.exe aparecem com frequência nos logs, mas raramente são os verdadeiros culpados: eles indicam que o erro aconteceu no kernel, não que o causaram.
Corrigindo o problema pelos drivers e pelos arquivos do sistema
Com o driver suspeito identificado, o primeiro passo é acessar o Gerenciador de Dispositivos via Win + X. Localize o dispositivo relacionado ao driver identificado, clique com o botão direito, acesse Propriedades e verifique se a opção “Reverter Driver” está disponível. Se estiver, use-a: ela restaura a versão anterior que funcionava corretamente. Quando a reversão não está disponível, baixar a versão anterior diretamente no site do fabricante é o caminho.
Removendo drivers de vídeo com DDU
Para drivers de vídeo, o processo merece atenção extra. O DDU (Display Driver Uninstaller), executado no Modo Seguro, remove completamente todos os arquivos do driver antes de reinstalar, evitando que resíduos da instalação antiga causem conflitos com a nova versão. Desconecte a internet durante o processo para impedir que o Windows reinstale automaticamente o driver problemático antes que você instale a versão correta.
Reparando arquivos de sistema com DISM e SFC
Depois de lidar com os drivers, é hora de verificar os arquivos de sistema. Abra o Prompt de Comando como administrador e execute primeiro o DISM:
DISM /Online /Cleanup-Image /RestoreHealth
Aguarde a conclusão completa, que pode levar até 30 minutos. O DISM repara o repositório de arquivos que o SFC usa como referência, por isso a ordem importa. Só então execute:
sfc /scannow
Executar o SFC antes do DISM reduz a eficácia dos dois comandos, pois o SFC pode tentar restaurar arquivos a partir de um repositório ainda corrompido. Para um passo a passo detalhado sobre esses comandos, veja o guia Corrigir erros do Windows com SFC e DISM: guia prático.
Testando a RAM para o erro IRQL_NOT_LESS_OR_EQUAL
O Windows já traz uma ferramenta de diagnóstico de memória integrada. Basta buscar “Diagnóstico de Memória do Windows” na barra de tarefas, escolher reiniciar e aguardar o resultado. Para um teste mais completo, o MemTest86 (gratuito em memtest86.com) roda direto pelo pen drive, antes mesmo do sistema operacional carregar, eliminando qualquer interferência do Windows durante o processo.
O MemTest86 leva aproximadamente uma hora para cada 8 GB de memória instalada. Qualquer erro detectado durante o teste confirma falha de RAM. Para identificar qual módulo está com problema, teste um de cada vez: retire todos, deixe apenas um, execute o teste completo e repita com o próximo. O módulo que gerar erros precisa ser substituído.
Se o computador não termina de inicializar por causa do crash, forçar três reinicializações seguidas pode ativar o Reparo Automático do Windows. A partir daí, acesse Solucionar Problemas, depois Opções Avançadas e Configurações de Inicialização: escolha a opção 4 para Modo Seguro ou a opção 5 para Modo Seguro com Rede. No Modo Seguro, o Windows carrega apenas drivers essenciais, o que quase sempre interrompe o loop. A partir dali você consegue desinstalar drivers, rodar SFC e DISM, executar a Restauração do Sistema ou analisar os arquivos de dump.
Quando o problema está no hardware e o que fazer
Se os crashes persistem mesmo após reinstalar drivers, reparar arquivos do sistema e testar a memória, o problema é provavelmente físico. Os indicadores mais concretos são: RAM reprovada no MemTest86, HD ou SSD com erros detectados pelo CHKDSK (chkdsk C: /f /r), superaquecimento documentado pelo monitoramento do sistema ou placa de vídeo apresentando artefatos visuais na tela.
Nesse ponto, a solução é trocar o componente defeituoso ou levar o equipamento a um técnico especializado. Vale chegar com informações em mãos: o nome do driver identificado pelo WhoCrashed, os resultados do MemTest86 e os logs do CHKDSK. Não existe comando ou ferramenta de software que conserte um módulo de RAM fisicamente danificado ou um SSD com muitos setores defeituosos, e ter esses dados agiliza bastante o diagnóstico do técnico.
Conclusão: da tela azul à solução em etapas
O erro IRQL_NOT_LESS_OR_EQUAL tem origem identificável e as ferramentas nativas do Windows são suficientes para resolver a maioria dos casos. A chave está em seguir a sequência certa: analisar o minidump para confirmar o driver responsável, corrigir ou reverter o driver, reparar os arquivos de sistema com DISM e SFC, e testar a RAM. O Modo Seguro entra como recurso de acesso quando o sistema não consegue inicializar normalmente.
Quem entende como o Windows organiza drivers e gerencia a memória chega à causa do problema muito mais rápido do que quem tenta soluções aleatórias. Esse tipo de raciocínio estruturado é o que diferencia um usuário que resolve o próprio problema de um que fica dependente de terceiros a cada erro. Se você quer ir além do diagnóstico reativo e aprender o Windows de verdade, os cursos do Professor Diogo Puiatti ensinam exatamente isso: não só clicar nos lugares certos, mas entender por que cada passo funciona.


Deixe um comentário