Diagnóstico de Problemas em PCs com telas azuis: leitura de erros e confirmação da causa

O que é uma BSOD e por que ela é “boa” para diagnóstico

A tela azul (BSOD) é uma interrupção forçada do Windows quando o sistema detecta uma condição crítica que pode corromper dados ou comprometer a estabilidade. Para diagnóstico, ela é útil porque normalmente deixa rastros: código de parada (Stop Code), possível driver/módulo envolvido e arquivos de despejo (dump) que permitem correlacionar o sintoma com uma causa provável.

O objetivo aqui não é “apagar” a BSOD, e sim identificar o padrão, coletar evidências e confirmar a causa com testes direcionados, evitando o “falso conserto” (quando a tela azul some por acaso, mas o problema permanece).

Quais informações coletar em uma BSOD

1) Código de parada e parâmetros

O Windows costuma mostrar um texto como IRQL_NOT_LESS_OR_EQUAL, MEMORY_MANAGEMENT, WHEA_UNCORRECTABLE_ERROR etc. Em dumps, esses erros aparecem como BugCheck com parâmetros (ex.: 0x0000003B e quatro valores). Esses parâmetros ajudam a diferenciar, por exemplo, falha de driver, corrupção de memória, instabilidade de CPU/IMC, problemas de armazenamento ou erros de hardware reportados via WHEA.

2) Driver/módulo citado

Às vezes a BSOD cita um arquivo .sys (ex.: nvlddmkm.sys, amdkmdag.sys, rtwlane.sys). Isso é uma pista, não uma sentença: o driver pode ser o culpado, ou apenas a “vítima” de RAM instável, overclock, corrupção de sistema ou falha de disco.

3) Padrões de ocorrência

• Quando ocorre: ao iniciar, ao logar, em idle, em jogo, em render, ao acordar do sleep, ao conectar periférico, ao instalar atualização.
• Frequência: aleatória, sempre após X minutos, sempre ao abrir um app específico.
• Gatilhos: rede/Wi‑Fi, GPU (3D), USB, áudio, armazenamento, virtualização, anti-cheat, antivírus.

4) Correlação com mudanças recentes

Registre tudo o que mudou nos últimos dias: atualização de driver (GPU/chipset/rede), atualização do Windows, troca de RAM, ativação de XMP/EXPO, undervolt/overclock, novo SSD, mudança de cabo/porta, software de baixo nível (RGB, monitoramento, overclock), antivírus, VPN, drivers de periféricos.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Como registrar o erro e anexar evidências

Checklist de evidências (mínimo recomendado)

• Foto da BSOD (celular) mostrando stop code e, se houver, o arquivo citado.
• Data/hora exata do evento e o que estava fazendo no momento.
• Minidumps e/ou dump completo (se disponível).
• Eventos do sistema relacionados (Kernel-Power, BugCheck, WHEA-Logger, Disk, Ntfs, storahci/nvme).
• Lista de mudanças recentes (drivers/BIOS/UEFI/Windows/hardware).

Onde encontrar dumps

• Minidumps: C:\Windows\Minidump\
• Dump de memória: C:\Windows\MEMORY.DMP

Se não houver dumps, verifique se o Windows está configurado para gravá-los (sem entrar em detalhes de telas): o tipo mais prático para triagem é “Despejo de memória pequeno (minidump)”.

Exportando eventos para anexar

No Visualizador de Eventos, filtre por Crítico e Erro no log Sistema no intervalo do crash e exporte o log (.evtx). Isso ajuda a ver se houve WHEA, falhas de disco, resets de driver de vídeo, ou desligamento inesperado.

Leitura rápida de minidump (triagem)

Para uma leitura inicial sem “mergulhar” em depuração avançada, use um visualizador de dumps (ex.: BlueScreenView/WhoCrashed) para extrair:

• Stop code / BugCheck
• Módulo/driver apontado
• Stack simplificada (se disponível)
• Data/hora e repetição do mesmo padrão

Interprete como hipótese: se o mesmo driver aparece em múltiplos dumps e o padrão de ocorrência combina (ex.: BSOD ao abrir jogo e driver de GPU aparece), a prioridade é alta. Se o driver varia muito e os stop codes são “genéricos” (memória, corrupção), suspeite de RAM/instabilidade/armazenamento.

Mapa prático: stop codes comuns e o que eles sugerem

Use a tabela como orientação de triagem. A confirmação vem dos testes e da repetição controlada.

Processo de triagem (passo a passo) para BSOD

Passo 1 — Estabeleça uma linha de base (reduzir variáveis)

• Se houver overclock/undervolt (CPU/GPU/RAM), volte para padrão (stock). Para RAM, desative XMP/EXPO temporariamente.
• Desative temporariamente softwares que injetam drivers/serviços de baixo nível: utilitários de RGB, overclock, monitoramento agressivo, antivírus de terceiros (quando aplicável), VPNs e drivers de periféricos não essenciais.
• Se a BSOD ocorre em cenário específico (jogo, render, sleep), anote o cenário para reproduzir depois.

Passo 2 — Atualizar ou reverter drivers (com critério)

O objetivo é testar a hipótese “driver”. Faça mudanças controladas (uma por vez) e registre.

• GPU: se o dump aponta driver de vídeo ou o padrão é em 3D, teste: (a) atualizar para versão estável/WHQL; (b) se começou após update, reverter para a versão anterior conhecida boa. Idealmente, faça instalação limpa do driver.
• Chipset/ME/PSP: atualize drivers do chipset e componentes de plataforma (especialmente em AMD/Intel recentes).
• Rede/Wi‑Fi/Bluetooth: se BSOD ocorre ao usar rede, jogos online, ou ao acordar do sleep, atualize/reverta drivers do adaptador.
• Armazenamento: drivers NVMe/IRST (quando usados) e firmware do SSD podem influenciar erros de I/O.

Regra prática: se a BSOD começou “depois de X”, priorize reverter X antes de atualizar outras coisas.

Passo 3 — Teste de RAM (para confirmar ou descartar instabilidade)

BSODs intermitentes e stop codes variados frequentemente envolvem memória (módulos, controlador de memória, XMP/EXPO, tensão/treinamento).

• Teste com configuração mínima estável: XMP/EXPO desligado, frequência JEDEC.
• Se houver múltiplos módulos, teste um módulo por vez e em slots diferentes (para separar módulo vs slot/placa-mãe).
• Use um teste dedicado (ex.: MemTest86) ou estresse de memória no Windows (ex.: TestMem5/OCCT). O importante é: tempo suficiente e repetibilidade.

Critério de confirmação: qualquer erro em teste de RAM é significativo. Se os erros somem ao desligar XMP/EXPO, a causa provável é instabilidade de perfil/IMC, não necessariamente “RAM queimada”.

Passo 4 — Verificar integridade do sistema (arquivos do Windows)

Corrupção de arquivos do sistema pode causar BSODs e erros de processos críticos. Rode, em Prompt/Terminal como administrador:

sfc /scannow

Se o SFC reportar que não conseguiu corrigir tudo, use DISM:

DISM /Online /Cleanup-Image /RestoreHealth

Depois, rode o SFC novamente. Registre os resultados (captura ou texto) para anexar ao caso.

Passo 5 — Verificar disco e I/O (para BSODs ligados a leitura/gravação)

• Cheque SMART com ferramenta do fabricante ou utilitário confiável.
• Rode verificação de disco:

chkdsk C: /scan

Se houver suspeita forte de corrupção/sectores problemáticos, planeje uma verificação mais profunda (pode exigir reinício):

chkdsk C: /f /r

Critério de confirmação: eventos recorrentes de Disk/Ntfs, realocações/erros SMART, ou falhas que desaparecem ao trocar cabo/porta/slot (SATA) ou ao mover NVMe de slot indicam causa no caminho de armazenamento.

Passo 6 — Checar temperaturas e comportamento sob carga

BSOD pode ser consequência de instabilidade térmica/energia, especialmente em carga (jogos, render, stress). Registre:

• Temperatura de CPU (package), GPU (core/hotspot), VRM (se disponível)
• Frequências e limites (throttling)
• Se a BSOD ocorre após aquecer (ex.: 10–30 min)

Faça testes separados para isolar:

• CPU: stress de CPU (sem GPU) para ver se WHEA/BSOD aparece.
• GPU: stress de GPU para ver se o driver de vídeo cai/BSOD aparece.
• Combinado: carga mista pode revelar limitação de fonte/VRM, mas use por último, após testes isolados.

Passo 7 — Overclock/undervolt: como tratar na triagem

Mesmo undervolt “leve” pode causar WHEA, travamentos e BSODs difíceis de reproduzir. Para diagnóstico:

• Volte para stock e confirme estabilidade por um período (ex.: 24–48h de uso normal + testes).
• Se quiser manter OC/UV, reintroduza uma mudança por vez e repita o teste que antes falhava.
• Se o problema volta ao reintroduzir a alteração, você tem um teste de confirmação forte.

Como definir testes de confirmação (evitar “falso conserto”)

O que é “falso conserto” na prática

É quando você muda algo (atualiza driver, limpa arquivos, mexe em configurações) e a BSOD não aparece por um tempo, mas sem prova de causalidade. Como BSOD pode ser intermitente, a ausência temporária não confirma correção.

Estrutura de confirmação: hipótese → ação → reprodução → evidência

• Hipótese: “Driver de GPU está causando BSOD em jogos.”
• Ação: instalar versão WHQL anterior (ou limpa) e remover utilitário de overclock.
• Reprodução: rodar o mesmo jogo/benchmark por X tempo, nas mesmas configurações.
• Evidência: ausência de novos dumps + logs sem erros de driver + estabilidade repetida em 3 sessões.

Critérios objetivos para considerar confirmado

• Repetibilidade: o problema some após a mudança e volta ao desfazer (A/B test), quando seguro fazer.
• Coerência de logs: desaparecem eventos correlatos (ex.: WHEA-Logger, resets de driver, erros de disco).
• Teste direcionado passa: RAM passa sem erros; stress de GPU não gera crash; verificação de sistema/disco sem corrupção.

Modelos práticos de registro (para suporte ou histórico)

Modelo de ficha de incidente

• Data/hora: 2026-01-25 21:43
• Stop code: IRQL_NOT_LESS_OR_EQUAL
• Módulo citado: rtwlane.sys
• Cenário: conectando Wi‑Fi / iniciando download
• Mudanças recentes: atualização do driver Wi‑Fi ontem
• Evidências anexas: foto da BSOD, Minidump\012526-12345-01.dmp, export System.evtx
• Ação aplicada: revertido driver Wi‑Fi para versão anterior
• Teste de confirmação: 3 ciclos de sleep/wake + 2h de download contínuo
• Resultado: sem BSOD, sem novos eventos críticos

O que anexar quando pedir ajuda

• Arquivo(s) .dmp (compactados)
• System.evtx do intervalo do crash
• Print/foto do stop code
• Lista de hardware (CPU, placa-mãe, RAM com modelo e XMP/EXPO, GPU, SSD/fonte)
• O que mudou recentemente e quais ações já foram testadas