Corrigir DPC_WATCHDOG_VIOLATION no Windows 11

Baixe o BlueScreenView de nirsoft.net — gratuito, sem instalação, lê os arquivos minidump que o Windows cria após cada crash. Abra, clique na entrada do crash mais recente, olhe no painel inferior a coluna “Caused By Driver”. Isso diz o arquivo .sys exato responsável. Leva trinta segundos e elimina a adivinhação que todo outro guia na internet quer que você faça.

Código de parada 0x00000133 significa que uma Chamada de Procedimento Adiado rodou mais tempo do que o Windows permite. DPCs são como drivers fazem trabalho de hardware sensível ao tempo — comunicando com a GPU, lendo do controlador SSD, processando pacotes de rede. O Windows dá a cada DPC um orçamento estrito de tempo. Se um driver o estoura sem terminar, o watchdog dispara e você recebe tela azul. Então isso é sempre um problema de driver. A questão é qual driver.

O PC gaming customizado de um cliente começou a travar no momento em que carregava qualquer jogo. Funcionava bem na área de trabalho, bem navegando, bem assistindo YouTube. Mas no segundo que um jogo começava a renderizar, tela azul. BlueScreenView mostrou nvlddmkm.sys na coluna Caused By Driver — o driver de display da NVIDIA. Ele estava na versão 572.21, que tinha um problema conhecido de timing DPC com placas RTX 40 sob carga pesada de shader. Iniciamos no Modo de Segurança, rodamos DDU para remover o driver completamente, instalamos a 566.36 do arquivo da NVIDIA. Nenhum crash desde então. Quatorze minutos.

Se BlueScreenView apontar para iaStorA.sys ou iaStorAC.sys, esse é o driver Intel Rapid Storage Technology e é a causa mais comum desse tela azul específico.

:(

Your PC ran into a problem and needs to restart. We're just collecting some error info, and then we'll restart for you.

For more information about this issue and possible fixes, visit
https://www.windows.com/stopcode

Stop code: DPC_WATCHDOG_VIOLATION

What failed: iaStorA.sys

42% complete

Controlador SATA e Firmware do SSD

A correção iaStorA é a resposta número um para DPC_WATCHDOG_VIOLATION desde o Windows 10, e ainda se aplica se sua máquina roda um SSD SATA ou disco rígido. Abra o Gerenciador de Dispositivos, expanda Controladores IDE ATA/ATAPI, clique direito no que estiver listado — geralmente “Controlador SATA/PCIe RST Premium Intel(R)” ou algo similar — clique em Atualizar driver, Procurar drivers no meu computador, Deixe-me escolher de uma lista, e selecione “Controlador AHCI SATA Padrão”. Reinicie. O que você fez foi trocar o driver SATA proprietário da Intel pelo genérico da Microsoft, que lida com timing de DPC de forma mais conservadora.

O detalhe que ninguém menciona. Se seu disco de boot é um SSD NVMe — e em qualquer máquina feita depois de 2021, provavelmente é — a correção do controlador AHCI SATA não faz nada. Discos NVMe não usam o controlador SATA de jeito nenhum. Rodam via stornvme.sys, que é um driver completamente diferente com um caminho de DPC completamente diferente. Se BlueScreenView mostra stornvme.sys, verifique o site do fabricante do SSD para atualização de firmware. Os Samsung 980 Pro e 990 Pro tiveram patches de firmware em 2025 que endereçavam especificamente timeout de DPC durante escritas aleatórias pesadas. WD, Kingston, Crucial — todos tiveram patches similares. O firmware gerencia como o SSD responde à pressão de profundidade de fila, e uma versão bugada vai travar tempo suficiente para acionar o watchdog.

Também vale verificar: se o BIOS da sua placa-mãe tem opção de modo SATA e está definido como RAID em vez de AHCI, mude para AHCI. O modo RAID carrega uma pilha de drivers diferente que introduz latência extra de DPC. Aviso — mudar o modo SATA após o Windows instalado pode impedir a inicialização. Talvez precise habilitar Safe Boot no msconfig primeiro, mudar a configuração do BIOS, iniciar no Modo de Segurança, depois desabilitar Safe Boot e reiniciar normalmente.

Drivers de GPU e Chipset

Se BlueScreenView nomeia nvlddmkm.sys, é o driver de display da NVIDIA. atikmpag.sys ou atikmdag.sys é AMD. igdkmd64.sys é gráficos integrados Intel. Drivers de GPU são a segunda causa mais comum depois de controladores de armazenamento porque renderização envolve cargas massivas de DPC — cada frame que a GPU processa dispara chamadas adiadas que precisam completar dentro da janela do watchdog. Se seus crashes de nvlddmkm.sys mostram SYSTEM_SERVICE_EXCEPTION em vez disso, a correção é o mesmo processo DDU mas o mecanismo de crash é diferente — exceção no código do driver em vez de timeout de DPC.

Não atualize pelo Gerenciador de Dispositivos. O Gerenciador puxa qualquer versão genérica que a Microsoft tem em cache, que geralmente está meses atrás da última do fabricante e às vezes é a versão exata causando crashes. Baixe diretamente de nvidia.com, amd.com/support, ou intel.com/support. Para NVIDIA especificamente, se o driver mais novo é o problema — o que acontece mais do que você imaginaria, as séries 570.x e 572.x tiveram múltiplos problemas conhecidos de DPC em placas RTX 30 e 40 — baixe o Display Driver Uninstaller, inicie no Modo de Segurança, rode DDU para remover todo vestígio do driver antigo incluindo chaves de registro e caches de shader, reinicie, depois instale uma cópia limpa. A série 566.x tem sido a mais estável para timing de DPC na nossa experiência.

Drivers de chipset importam mais do que as pessoas percebem para esse erro específico. Seu driver de chipset controla como cada dispositivo na placa-mãe se comunica com a CPU, e um desatualizado pode adicionar overhead suficiente a chamadas DPC individuais para empurrá-las além do limite do watchdog. Baixe seu driver de chipset da página de suporte do fabricante da placa-mãe — ASUS, MSI, Gigabyte, ASRock — não diretamente da Intel ou AMD, porque versões OEM às vezes incluem ajustes de gerenciamento de energia específicos da placa. Placas AMD B550 e B650 em particular tiveram atualizações de firmware AGESA em 2025-2026 que mudaram o comportamento de agendamento de DPC.

Mais uma coisa que vejo disparar isso mais ou menos uma vez por mês — perfis XMP de memória. XMP faz overclock na sua RAM além da especificação nominal, e se o controlador de memória da CPU não aguenta a velocidade com confiança, DPCs envolvendo E/S mapeada em memória começam a dar timeout intermitente. Os crashes parecem aleatórios porque dependem exatamente de quais endereços de memória são atingidos. Entre no BIOS e desative XMP temporariamente. Se os crashes pararem, deixe desligado ou desça um nível de XMP.

Correções em Nível de Sistema

Se BlueScreenView aponta para ntoskrnl.exe em vez de um driver de terceiros específico, o crash aconteceu no nível do kernel e pode ser arquivos de sistema corrompidos. Execute sfc /scannow em um terminal admin, depois DISM /Online /Cleanup-Image /RestoreHealth, depois sfc /scannow novamente. O primeiro passe do SFC identifica corrupção, DISM baixa arquivos fonte limpos da Microsoft, o segundo passe do SFC usa essas fontes limpas para realmente reparar.

Inicialização Rápida causa esse erro mais do que deveria. Ela salva uma imagem parcial de hibernação no desligamento e retoma a partir dela no boot em vez de fazer uma inicialização nova de drivers. Se o estado salvo inclui um driver em um estado estranho de processamento de DPC, cada boot recria o problema. Painel de Controle, Opções de Energia, Escolher a função dos botões de energia, Alterar configurações não disponíveis no momento, desmarque Ativar inicialização rápida.

Se nada disso ajudou, teste sua RAM. memtest86 em um pendrive USB, deixe rodar durante a noite. Já vi DPC_WATCHDOG_VIOLATION rastreado até um único pente de RAM ruim três vezes só este ano — o DIMM falhando corrompe os dados de DPC do driver no meio da execução e o timing desanda. Para análise de tela azul mais profunda incluindo leituras completas de minidump no WinDbg, ou se está recebendo múltiplos códigos de parada diferentes junto com DPC_WATCHDOG, nosso diagnóstico de BSOD cobre toda a pilha de driver e hardware — puxamos minidumps, identificamos o driver e versão exatos, e ou corrigimos na mesma sessão ou dizemos exatamente qual hardware trocar.