Defender 高 CPU 排查与调优

Diagnóstico e Otimização de Alto Consumo de CPU do Defender

Qual problema esta skill resolve

Em máquinas Windows de desenvolvimento, a proteção em tempo real do Microsoft Defender verifica cada leitura de arquivo. Quando um processo lê muitos arquivos (indexação do IntelliJ IDEA, varredura de projetos pelo Codex, find / percorrendo o disco, Maven baixando dependências, I/O interno de WSL/Docker), o Defender se torna uma esteira de verificação sem fim, elevando o CPU do MsMpEng.exe para 50%+, causando travamentos no sistema.

O insight central deste fluxo é: Alto CPU do Defender quase nunca é um problema do Defender em si, mas sim algum processo gerador de alto I/O que está acionando continuamente a proteção em tempo real. Portanto, a chave da investigação não é "ajustar parâmetros do Defender", mas sim localizar a fonte do gatilho e removê-la do caminho de verificação com exclusões precisas – resolvendo a lentidão sem comprometer a postura de segurança.

Fluxo de Diagnóstico

Passo 0: Confirme se é o Defender e em qual "métrica" de CPU

A coluna de CPU do Gerenciador de Tarefas (Task Manager) e o contador de desempenho \Process(*)\% Processor Time usam métricas diferentes: o contador em máquinas multi-core pode exceder 100% por processo (soma de 100% por núcleo), enquanto o Gerenciador de Tarefas divide o valor do contador pelo número de núcleos. Portanto, "61,2%" no Gerenciador pode corresponder a 766% no contador (em uma máquina de 20 núcleos). Ambos os valores estão corretos, não tire conclusões usando a métrica errada.

Para confirmar rapidamente o uso real do MsMpEng (na métrica do Gerenciador de Tarefas):

$cores = $env:NUMBER_OF_PROCESSORS
$c = (Get-Counter '\Process(MsMpEng*)\% Processor Time').CounterSamples | Where-Object { $_.InstanceName -like 'msmpeng*' } | Select-Object -First 1
"MsMpEng: Contador=$([math]::Round($c.CookedValue,1))%  Equivalente Gerenciador=$([math]::Round($c.CookedValue/$cores,1))%  (máquina de $cores núcleos)"

Se o Gerenciador mostra alto mas o contador é consistentemente 0, é um valor desatualizado não atualizado do Gerenciador – basta reabri-lo, não mexa no Defender.

Passo 1: Localize a fonte do gatilho (com correlação, não intuição)

As causas raiz do alto CPU do Defender se dividem em três categorias, com métodos de localização distintos:

Causa Raiz	Característica	Como Confirmar
Proteção em tempo real acionada por processo externo (mais comum)	CPU do MsMpEng oscila em pulsos, com um processo externo gerando alto I/O simultaneamente	Amostragem contínua: encontre qual processo tem I/O alto quando o MsMpEng sobe
Varredura programada/em segundo plano	CPU consistentemente alta, pouca oscilação; ScanRunning com valor ou tarefa agendada em execução	Get-MpComputerStatus para ScanRunning; Get-ScheduledTask -TaskPath '\Microsoft\Windows\Windows Defender\*'
Tarefas internas do Defender (validação pós-atualização, amostragem na nuvem, etc.)	MsMpEng tem o maior I/O de Leitura, mas nenhum processo externo com I/O alto correspondente	Amostragem: veja se o I/O do próprio MsMpEng supera em muito os demais processos

Ferramenta de diagnóstico chave: Execute scripts/diag-mpcpu.ps1. Ele faz amostragem contínua por alguns segundos, registrando simultaneamente o CPU do MsMpEng e os IO Data Bytes/sec de cada processo. Interpretação:

• Se um processo tem I/O alto quando o MsMpEng também sobe → esse processo é a fonte do gatilho, vá para o Passo 2 para tratar a causa raiz
• Se o MsMpEng tem a maior Leitura própria, sem I/O externo alto → vá para o Passo 3 (tarefas em segundo plano/varredura)
• Se o MsMpEng fica próximo de 0 durante todo o período → o problema não está mais no Defender, procure em outro lugar (o usuário pode estar vendo um valor desatualizado do Gerenciador de Tarefas)

Passo 2: Trate a causa raiz – adicione exclusões para a fonte do gatilho

Existem dois tipos de exclusão, e é importante entender a diferença:

• Exclusão de Processo (ExclusionProcess): Especifica o nome do processo (ex.: idea64.exe). Quando esse processo lê um arquivo, não aciona a verificação, mas se o mesmo arquivo for acessado por outro processo, ainda será verificado. Preciso, seguro. Use este tipo primeiro.
• Exclusão de Caminho (ExclusionPath): Especifica um diretório. Todos os arquivos nesse diretório não são verificados por nenhum processo (incluindo navegadores, EDR). Adequado para cenários como cache / disco virtual – "é apenas um arquivo de dados, não deveria ser verificado por quem quer que o acesse". Não use para excluir diretórios de código-fonte do projeto – o código-fonte deve ser protegido pela exclusão de processo (apenas a ferramenta de desenvolvimento não verifica ao ler, mas se o navegador baixar algo para o mesmo diretório, ainda será verificado). É por isso que a derivação de caminhos do gen-exclusions.ps1 só produz exclusões para cache / disco virtual / raiz de instalação de ferramentas, e nunca exclui automaticamente diretórios de projeto.

Por que exclusão de processo tem prioridade: A exclusão de caminho remove a proteção em tempo real de todos os arquivos no diretório para todos os processos; a exclusão de processo só libera para uma ferramenta específica, com uma superfície de ataque muito menor. Por exemplo, excluir o processo codex.exe significa que, quando o Codex lê seu projeto, não verifica, mas se o navegador baixar algo para o mesmo diretório, ainda será verificado – é exatamente isso que queremos.

Execute scripts/gen-exclusions.ps1 – ele escaneia os processos de desenvolvimento em execução, corresponde a padrões de ferramentas conhecidas e gera automaticamente as exclusões de processo e caminho recomendadas. Por padrão, é executado em DryRun (mostra sugestões + justificativa); adicione -Apply para escrever as exclusões no Defender. É idempotente e faz backup das exclusões atuais antes de aplicar.

Passo 3: Tratamento de causas raiz de varredura em segundo plano

Se for uma varredura programada / manutenção automática em execução (ScanRunning com valor, tarefa agendada State=Running), normalmente espere terminar – não deve ser morta à força. Esta é uma manutenção de segurança necessária do Defender. Se ocorrer repetidamente em horários inconvenientes, ajuste o agendamento:

# Verificar varreduras programadas
Get-ScheduledTask -TaskPath '\Microsoft\Windows\Windows Defender\*'
# Ajustar horário da varredura rápida (ex.: 03:00 todos os dias) – isso substitui a configuração de varredura programada existente
Set-MpPreference -ScanScheduleQuickScanTime 03:00:00

Se for uma validação completa após atualização de definições (ocorre ocasionalmente), geralmente é única e termina sozinha.

Passo 4: Verificação

Após adicionar as exclusões, reproduza a carga alta de I/O original (reabra a IDE para indexar, execute find novamente, deixe o Codex escanear o projeto) e execute diag-mpcpu.ps1 novamente. O critério de sucesso é: com a mesma carga de I/O, o MsMpEng cai do pico anterior para perto de 0. Se não cair, significa que as exclusões não cobriram a fonte real do gatilho – volte ao Passo 1 e veja na saída do diagnóstico qual processo ainda está subindo simultaneamente.

Limites de Segurança – Isso nunca deve ser excluído

Exclusões reduzem a proteção em tempo real do caminho/processo correspondente, portanto devem ter limites. Nunca adicione os itens abaixo à exclusão, independentemente de quanto CPU possam economizar (a lista completa e autoritativa é a $denyProcs e $denyPathPrefix do script scripts/gen-exclusions.ps1; a lista na documentação é apenas ilustrativa):

• Processos do sistema: svchost.exe, dllhost.exe, smartscreen.exe, conhost.exe, lsass.exe, csrss.exe, etc.
• Navegadores e seus WebViews: msedge.exe, chrome.exe, msedgewebview2.exe – downloads de navegadores são a principal porta de entrada de malware, mantenha a verificação
• Clientes de segurança/controle: EDR corporativo, clientes VPN (como ECAgent da Sangfor, CrowdStrike, SentinelOne) – mexer neles pode disparar alertas de conformidade e eles são, por definição, linhas de defesa
• Diretório do usuário inteiro / raiz do disco do sistema: Granularidade muito grossa, equivalente a ficar exposto
• Extensões executáveis como *.jar, *.exe, *.dll, *.ps1: Mantenha a verificação de executáveis. Extensões de exclusão são apenas para artefatos de compilação (*.class) ou logs (*.log) – que não são executáveis.

Princípio de decisão: As exclusões devem mirar nos arquivos que ferramentas de desenvolvimento confiáveis leem durante seu trabalho normal, e não em "excluir tudo para economizar CPU".

Diagnóstico Avançado: Performance Recorder

Quando o script de diagnóstico ainda não localiza com precisão, use o gravador de desempenho oficial do Defender (requer administrador) – ele fornece um relatório preciso de onde o MsMpEng está gastando tempo, em caminhos/processos específicos:

New-MpPerformanceRecord -RecordTo C:\perf.mpdr   # Coleta por 60s (reproduza o alto CPU durante esse período)
# O relatório apontará os caminhos e processos que mais consomem CPU – use isso para adicionar exclusões precisas

Arquivos de Referência

• references/common-exclusions.md – Lista categorizada de exclusões recomendadas para ferramentas de desenvolvimento comuns (IDE / Java / Node / WSL / Docker / Assistentes de Código com IA / Cache de Build), incluindo considerações de segurança para cada categoria. Usado para verificar a cobertura ao gerar exclusões.
• scripts/diag-mpcpu.ps1 – Script de amostragem de diagnóstico
• scripts/gen-exclusions.ps1 – Script para gerar e aplicar exclusões automaticamente (modo de pré-visualização padrão)