Latência de DPC: quando quem engasga é um driver

Latência de DPC é o tempo em que um driver segura um núcleo do processador dentro de uma interrupção ou de uma deferred procedure call: esse núcleo não desenha nada e não lê entrada, então um quadro ou relatório que esteja atrás dele chega atrasado, e nenhum gerenciador de tarefas mostra isso. Uma retenção de 1 ms custa um relatório a 1000 Hz; de 4 ms para cima, os tempos de quadro não conseguem se manter estáveis.

Você já passou pela lista. Nada está rodando, as temperaturas estão boas, o disco é rápido, o jogo está num SSD, e a máquina continua dando solavancos. O Gerenciador de Tarefas mostra um sistema ocioso. O gráfico de tempo de quadro mostra o quadro atrasado, mas não diz nada sobre por que ele atrasou.

Existe uma causa que explica exatamente esse formato, e ela é invisível em todas as ferramentas que a maioria das pessoas abre, porque acontece por baixo delas.

Primeiro, a frase honesta. A solução para um driver que segura um núcleo é esse driver, do fabricante dele. A parte do w0a é a medição, o nome do arquivo e o reparo de valores que ferramentas antigas deixaram para trás. A única chave que ele oferecia por perto, direcionar as interrupções de um dispositivo para núcleos escolhidos, é só leitura desde 8 de outubro de 2026, porque nenhum A/B em jogo mostrou um quadro ganho com ela.

O que é latência de DPC?

Um dispositivo — uma placa de rede, uma controladora de disco, um chip de som, uma controladora USB — precisa da atenção do processador. Ele levanta uma interrupção, e o Windows roda na hora a rotina de serviço de interrupção do driver. Essa rotina roda acima de qualquer prioridade de thread que exista: não é "prioridade alta", é fora do agendador de threads por completo. Nada mais pode ser agendado naquele núcleo até ela retornar.

Como esse é um lugar caro para se estar, espera-se que os drivers façam o mínimo ali e adiem o resto para uma chamada adiada — um DPC —, que roda um instante depois, ainda à frente de qualquer thread naquele núcleo.

Enquanto uma das duas está executando, aquele núcleo não desenha nada e não lê entrada nenhuma. Se a sua thread de renderização estava nele, o seu quadro atrasa. Se o relatório do seu mouse estava na fila atrás dela, a sua entrada atrasa. E nenhum dos dois eventos aparece num gerenciador de tarefas, porque não existe processo a que atribuí-los.

Por que 1 ms de latência de DPC é muito?

É a conta que faz isso valer a perseguição:

• Com 1000 Hz de taxa de consulta, chega um relatório por milissegundo. Uma retenção de 1 ms custa um relatório.
• A 240 Hz, um quadro tem 4,2 ms. Uma retenção de 1 ms é cerca de um quarto do orçamento de um quadro gasto em nada.
• De 4 ms para cima, a máquina não consegue manter um tempo de quadro estável por mais que você mude outras coisas — e é por isso que isto vem antes de todos os outros itens da sua lista, não depois deles.

Como medir a latência de DPC?

O Teste de Latência do w0a abre uma sessão de rastreamento no kernel e registra, durante doze segundos de movimento real do mouse, por quanto tempo cada driver segurou um núcleo. Ele precisa de direitos de administrador. Por que o teste pede doze segundos trata da duração; como ler o teste de latência trata das cores.

Dois resultados não são respostas, e os dois são relatados como tal em vez de serem arredondados para "limpo":

• A sessão não pôde ser aberta. Um driver de anti-cheat pode ter tomado o rastreamento de kernel para si. Feche o jogo e meça de novo.
• A sessão abriu e não entregou nada. Nenhum Windows em funcionamento tem zero execuções de driver em doze segundos, ou seja, é uma medição que não aconteceu. Rode de novo.

Há um terceiro caso, mais sutil: uma sessão que perdeu eventos pode ter deixado passar a pior execução inteira, então a página avisa que aquele número pode não ser o pior de verdade. É o mesmo princípio que a análise de engasgos aplica em todo lugar — uma regra que não pôde rodar conta como não verificada, nunca como limpa.

Os números, exatamente

Lendo a lista

Cada driver aparece com o nome do arquivo dele, a retenção isolada mais longa, a fatia que ocupou do tempo medido e quantas vezes rodou. Ordene pela retenção mais longa; é esse o número que te custa um quadro.

Duas leituras que as pessoas fazem errado:

• Uma linha âmbar não é um problema que você precisa consertar. Ela é um candidato. Sem sintoma, ela não explica nada, e um monte de máquina saudável carrega uma.
• Um tratador de interrupção longo é pior que uma chamada adiada longa do mesmo tamanho. Durante uma chamada adiada, outras interrupções ainda podem ser atendidas; durante um tratador de interrupção, absolutamente nada entra naquele núcleo. A página marca quando o pior caso de um driver foi uma interrupção.

Qual arquivo é qual, e o que fazer com cada um

O nome do arquivo é a pista inteira, e a família a que ele pertence decide qual é a solução:

Um driver de filtro merece uma linha própria aqui. Ferramentas de modelagem de tráfego e de roteamento de conexão passam cada pacote por um driver delas, e solavancos de rede de vários segundos são o efeito colateral mais conhecido delas; a análise de engasgos as nomeia quando as encontra. O mesmo vale para pacotes de macro e programas de iluminação que instalam um filtro no caminho do mouse e do teclado.

Como resolver uma latência de DPC alta?

A solução é atualizar aquele driver específico, pelo fabricante do hardware. Não o sistema inteiro, não por um programa atualizador de drivers, e não reinstalando o Windows. A página nomeia o arquivo com precisão justamente para você conseguir descobrir de qual dispositivo ele é.

O que não resolve isto, e é recusado aqui exatamente por isso: sobrescritas de resolução do timer, valores de gerenciamento de memória do kernel (DisablePagingExecutive, LargeSystemCache) e as listas de registro que circulam sob a palavra "latência". Nenhum deles muda por quanto tempo um driver segura um núcleo, porque quem segura é o código do driver. Desligar dispositivos a esmo também não é diagnóstico — embora desligar um dispositivo como teste, com uma medição antes e outra depois, seja um experimento perfeitamente válido. O mesmo vale para os valores de dispositivo que circulam junto com essas listas: MSISupported troca o modo de interrupção de um dispositivo e, configurado errado, o resultado pode ser uma tela preta, então o w0a nunca o escreve, e o cartão de reparo de direcionamento de interrupções mais abaixo não mexe nele.

As duas configurações por perto em que o w0a mexe

Política de interrupção do dispositivo: só leitura, com um cartão de reparo

Onde o Windows a guarda: por dispositivo, em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\<device>\<instance>\Device Parameters\Interrupt Management\Affinity Policy. DevicePolicy (DWORD) escolhe como as interrupções do dispositivo são distribuídas; quando vale 4, "processadores especificados", AssignmentSetOverride é a máscara dos processadores que elas podem usar.

Padrão do Windows: nenhum dos dois valores presente. O Windows então calcula a distribuição sozinho, e a Microsoft recomenda a política padrão sempre que ela se aplica.

O que o w0a faz: ele lê esses valores e não os escreve. Desde 8 de outubro de 2026, o direcionamento que ele oferecia na página Teste de Latência não existe mais, por três motivos: nenhum A/B em jogo mostrou um quadro ganho com ele, a Microsoft recomenda a distribuição que o Windows calcula, e uma máscara errada é um dispositivo que não inicia.

Caminho de volta: se uma ferramenta fixou as interrupções de um dispositivo e algo quebrou — um mouse que cai, "Código 10" no Gerenciador de Dispositivos —, o cartão direcionamento de interrupções do dispositivo apaga os dois valores de todos os dispositivos PCI, incluindo o direcionamento deixado por versões antigas do w0a. Ele só pede reinício quando realmente removeu alguma coisa, e não mexe em MSISupported.

"Sob carga: sem controle de fluxo, moderação de interrupção e coalescência de segmentos" (página Conexão)

O que escreve: 0 na palavra-chave *FlowControl do adaptador de rede, em todo adaptador que a declara. *InterruptModeration, *RscIPv4 e *RscIPv6 só são escritos em máquinas com pelo menos seis núcleos físicos, e só em adaptadores que se sabe que rodam abaixo de 2,5 Gbit/s; nessas máquinas a caixa também desliga a coalescência de segmentos no nível da pilha de rede, a menos que ela já esteja desligada.

Por que a moderação fica ligada em máquinas menores: com a moderação e a coalescência ambas desligadas, cada pacote recebido vira a própria interrupção em vez de uma por intervalo de moderação, e a carga de chamadas adiadas cai no núcleo que recebe. Então desligar a moderação não é um jeito de encurtar a linha do driver de rede no Teste de Latência: pela descrição do próprio w0a, o que ela remove é a espera de dezenas a centenas de microssegundos que um pacote passa no adaptador até o temporizador do lote acabar, e o que ela acrescenta é uma interrupção por pacote. O efeito dela na lista de drivers não foi medido. Se o driver de rede é a sua linha, rode o teste com a caixa aplicada e sem ela.

O que a própria caixa promete: microssegundos, no ping sob carga. A mensagem dela diz que o ping médio não muda.

Quando vale: quando o adaptador reinicia; o w0a pede reinício sempre que escreveu alguma coisa.

Caminho de volta: o cartão offloads do adaptador de rede devolve os descarregamentos por hardware, a moderação de interrupções, o Energy Efficient Ethernet, a suspensão seletiva e os buffers de recepção aos padrões do próprio driver, como o driver os declara.

Confira você mesmo

Estes comandos só leem. No prompt de comando ou no PowerShell:

reg query "HKLM\SYSTEM\CurrentControlSet\Enum\PCI" /s /v DevicePolicy
reg query "HKLM\SYSTEM\CurrentControlSet\Enum\PCI" /s /v AssignmentSetOverride

Uma resposta dizendo que a busca terminou sem nenhuma correspondência (no Windows em inglês, End of search: 0 match(es) found.) significa que nenhum dispositivo tem uma substituição: o padrão do Windows. Uma correspondência aparece listada sob a chave em que foi encontrada, e a parte PCI desse caminho identifica o dispositivo.

No PowerShell, para o adaptador de rede:

Get-NetAdapterAdvancedProperty -Name "*" -RegistryKeyword "*FlowControl","*InterruptModeration","*RscIPv4","*RscIPv6" -AllProperties

Isso lista a configuração atual de cada adaptador para as quatro palavras-chave que a caixa da página Conexão pode escrever. Um adaptador que não aparece para uma palavra-chave não a declara, e a caixa não escreve nada ali.

Depois, meça de novo

Mesmo método, mesmos doze segundos, mesma máquina. A página compara com a sua execução anterior e relata uma mudança abaixo de 5% como nenhuma mudança, não como melhoria, porque duas execuções numa máquina intocada já diferem em alguns por cento de qualquer jeito — a mão se move diferente a cada vez.

Se a linha do driver baixou e o engasgo não, você aprendeu algo de verdade: esta não era a sua causa, e por que os jogos engasgam no Windows 11 tem o resto da lista. Se o que você tem é uma taxa de quadros que cai e fica caída em vez de um solavanco, nunca foi isto — a lista é quedas repentinas de FPS.

Relacionados

• Como ler o teste de latência
• Por que os jogos engasgam no Windows 11 (e como achar a causa real)
• Como diminuir o input lag no PC: o que o software encurta e o que não
• O que a análise de engasgos procura
• Por que o teste pede doze segundos de movimento do mouse
• Tweaks de rede