Build lento por causa do Defender: exclua a pasta certa, não a proteção

O build da solução .NET leva mais de três minutos, o ventilador dispara e o Gerenciador de Tarefas mostra o "Antimalware Service Executable" no topo. Um tutorial promete resolver com um comando que desliga a proteção em tempo real. Resolve o build e deixa sem vigilância a mesma máquina que abre e-mail, baixa pacote da internet e guarda a chave SSH da produção. A resposta curta: meça primeiro, exclua só as pastas de build e de cache de pacotes que o relatório do próprio Defender apontar, ou mova o código para uma Dev Drive. Desligar o antivírus inteiro troca alguns segundos por uma porta aberta.

Os comandos abaixo valem para o Microsoft Defender Antivírus no Windows 10 e 11. Em máquina gerenciada pela empresa, as exclusões costumam ser definidas pela TI; nesse caso, leve os números para eles em vez de tentar contornar a política.

Por que o antivírus deixa o build lento

A proteção em tempo real examina arquivos quando eles são abertos, criados ou alterados. Um build moderno faz exatamente isso em massa: restaura milhares de arquivos de pacotes, gera centenas de arquivos intermediários e escreve DLLs e executáveis novos a cada compilação. Cada um desses eventos pode disparar uma verificação. Com node_modules, pastas obj e bin e caches de NuGet, a conta chega a dezenas de milhares de arquivos por build.

A proteção não é inútil por isso. É ela que pega o pacote malicioso baixado por engano, o anexo com macro, o executável que alguém mandou pelo chat. O objetivo é tirar da verificação o que você mesmo gera e confia, mantendo vigiado tudo o que chega de fora.

Como medir e excluir só o necessário, passo a passo

1. Meça o build atual, sempre do mesmo jeito, para ter um número de partida.
2. Grave uma sessão de desempenho do Defender enquanto o build roda.
3. Leia o relatório e veja quais pastas, extensões e processos geraram mais verificação.
4. Exclua apenas pastas específicas de saída de build e de cache de pacotes.
5. Meça de novo. Se o ganho for suficiente, pare.
6. Revise as exclusões de tempos em tempos e remova as que perderam o motivo.

Medir o tempo do build

No PowerShell, rode o build completo três vezes e anote os tempos. Use --no-incremental para que cada execução faça o mesmo trabalho:

PS C:\src\Loja> Measure-Command { dotnet build .\Loja.sln --no-incremental } | Select-Object TotalSeconds

TotalSeconds
------------
    190,4127

Os números do exemplo são fictícios, mas o formato é o que você verá. Repita para ter uma média: a primeira execução costuma ser mais lenta por causa de cache de disco.

Descobrir o que o Defender está varrendo

O Defender tem um analisador de desempenho próprio, disponível nas versões atuais. Em um PowerShell como administrador, comece a gravação, rode o build em outro terminal e volte para encerrar com Enter:

PS C:\> New-MpPerformanceRecording -RecordTo C:\temp\build.etl

PS C:\> Get-MpPerformanceReport -Path C:\temp\build.etl -TopFiles 10 -TopExtensions 10 -TopProcesses 10

O relatório lista os arquivos, extensões e processos que mais consumiram tempo de verificação. Num projeto .NET típico, aparecem as pastas obj e bin da solução e o cache de pacotes do NuGet, em %USERPROFILE%\.nuget\packages. Num projeto Node, node_modules. Esses são os candidatos à exclusão, e só eles.

Excluir pastas específicas

PS C:\> Add-MpPreference -ExclusionPath "C:\src\Loja\artifacts"
PS C:\> Add-MpPreference -ExclusionPath "$env:USERPROFILE\.nuget\packages"

PS C:\> (Get-MpPreference).ExclusionPath

PS C:\> Remove-MpPreference -ExclusionPath "C:\src\Loja\artifacts"

Uma dica que facilita: configure o build para gravar a saída numa pasta única, como artifacts, em vez de espalhar bin e obj por cada projeto. Assim uma exclusão cobre tudo, em vez de dezenas. Prefira sempre exclusão por pasta a exclusão por processo: excluir node.exe ou dotnet.exe libera qualquer arquivo que esses programas toquem, inclusive um script malicioso executado por eles.

Repare no que não entra na lista: a pasta de código-fonte inteira, a pasta Downloads, a pasta temporária do sistema e o disco C:. É por esses caminhos que coisa de fora chega à máquina.

A alternativa sem exclusão: Dev Drive

No Windows 11, a Dev Drive é um volume formatado em ReFS pensado para código e builds. Em Configurações, ela é criada pela área de discos e volumes do armazenamento. Numa Dev Drive confiável, o Defender opera em modo de desempenho: a verificação passa a ser assíncrona, sem segurar a abertura de cada arquivo, e a proteção continua ativa. Para muitos projetos, mover o repositório e os caches de pacotes para lá resolve sem nenhuma exclusão manual. Confira na documentação da Microsoft os requisitos da sua versão do Windows antes de migrar.

Quando o alarme é o assunto, não o atraso

Às vezes o Defender não está só lento: ele bloqueia o executável que você acabou de compilar. Pode ser falso positivo, comum em binários novos e sem assinatura. Pode ser uma dependência que você não auditou. Antes de excluir a pasta, olhe o histórico de proteção na Segurança do Windows e veja o nome da ameaça e o arquivo apontado. Se for seu código, envie o arquivo à Microsoft como falso positivo e assine os binários que você distribui. Se for uma dependência, investigue antes de seguir; o post dependência com cadeado mostra como travar versões e saber o que entrou.

Ensinar "desligue o antivírus para funcionar" num README ou num tutorial é pior do que um build lento: quem lê repete o gesto no computador de casa e no da empresa. O post desligar o antivírus não é passo de tutorial trata desse risco do ponto de vista de quem usa o computador no dia a dia.

Erros comuns

• Desligar a proteção em tempo real "só durante o build". Ninguém lembra de religar, e a máquina fica dias sem vigilância.
• Excluir o disco inteiro ou a pasta do usuário. Downloads, anexos e pacotes baixados passam sem verificação.
• Excluir processos como node.exe ou powershell.exe. Qualquer script executado por eles escapa da verificação.
• Excluir sem medir. Você acumula exclusões que não mudaram o tempo do build e só reduziram a proteção.
• Ignorar um alerta no seu próprio executável. Pode ser uma dependência comprometida, e você estaria distribuindo o problema.
• Contornar a política da empresa em máquina gerenciada. Além do risco, a TI perde a visibilidade de que precisa para responder a um incidente.

Checklist

• Você tem o tempo do build antes e depois de qualquer mudança.
• As exclusões vieram do relatório de desempenho, não de um palpite.
• Só há exclusões de pastas de saída de build e de cache de pacotes.
• Nenhum processo genérico está excluído.
• A proteção em tempo real está ligada (confira na Segurança do Windows).
• Alertas em binários próprios foram investigados, e os falsos positivos, reportados.
• A lista de exclusões é revisada quando um projeto é arquivado.

Rode (Get-MpPreference).ExclusionPath num PowerShell como administrador agora. Cada caminho da lista tem um motivo que você consegue explicar, e quanto tempo de build cada um deles realmente devolveu?