FIELD NOTES

Software engineering in a secure Windows environment

windowsdefenderdevelopment

Builds are an awkward workload for endpoint security: thousands of small files, short-lived compiler processes, package extraction, and constant rewrites. Real-time antivirus scanning can add latency to that I/O. IDE indexing and dependency restores suffer too; JetBrains documents the same pattern.

Defender Antivirus isn't the entire security stack. EDR and DLP agents can add inspection work; application control, ASR rules, and Controlled Folder Access can block tools or writes outright. A slow build and a blocked build need different investigations. Microsoft's exclusions overview explains why an antivirus exclusion isn't a universal allowlist.

Measure the scan cost

Use Defender's performance analyzer before changing policy. This PowerShell captures a trace, then ranks processes, files, and extensions. Run it as administrator; reproduce one build in a separate, normal developer terminal, then press Enter in the recording window.

# Elevated Windows PowerShell 5.1; current Defender platform
$trace = Join-Path $env:TEMP ("Defender-build-{0}.etl" -f [guid]::NewGuid())
New-MpPerformanceRecording -RecordTo $trace
Get-MpPerformanceReport -Path $trace `
    -TopProcesses 10 -TopFiles 10 -TopExtensions 10
# Drill into the file types touched by the busiest processes:
Get-MpPerformanceReport -Path $trace `
    -TopProcesses 5 -TopExtensionsPerProcess 5

Scan duration is not elapsed build time lost: scans can overlap, and this trace doesn't measure other security agents. Time the same command and commit separately, compare clean and incremental builds, and keep dependency-cache state consistent. Repeat after each change. The report cmdlet reference covers the drill-down options. Traces contain local paths and process details; review them before sharing.

Follow the tool vendor's paths

An IDE's documented project, intermediate-output, and cache paths matter. Follow the recommendations for the actual product/version, map them to your machine, and agree the smallest useful scope with the security team. Recheck after upgrades or cache relocation. JetBrains' guidance is a useful example; it isn't a universal Windows exclusion list.

Don't turn a hot .dll entry into a machine-wide extension exclusion, or exempt an entire user profile. A process exclusion also has different semantics from excluding that executable: it can exclude files the process opens. Microsoft's exclusion guidance is the reference for those boundaries. Keep exclusions centrally managed where policy requires it.

Put project I/O on a Dev Drive

Dev Drive uses ReFS for repositories, package caches, and build intermediates. Windows 11 build 22621.2338 or later, at least 8 GB RAM, 50 GB free space, and administrator rights are prerequisites. Move the busy paths too: a repository on D: with its package cache still on C: only moves part of the workload.

On a trusted Dev Drive, Defender performance mode defers scans until after file-open operations. Protection remains, with a trade-off compared with synchronous scanning. It needs Defender as the primary antivirus, current components, and real-time protection enabled. Other volumes retain their normal protection; this isn't a fix for every MsMpEng.exe CPU spike.

For a new, empty volume already assigned D: (50 GB or larger), this is the basic configuration. Run it in PowerShell as administrator. The format command erases the volume's contents; it isn't an in-place conversion of an existing data drive.

Format-Volume -DriveLetter D -DevDrive -NewFileSystemLabel "Dev Drive" -Confirm -ErrorAction Stop
fsutil devdrv trust D:
Set-MpPreference -PerformanceModeStatus Enabled
fsutil devdrv query D:

D: becomes the Dev Drive for source, caches, and build output. Adjust the letter and label to suit your layout. Antivirus filters remain attached by default; enterprise policy still applies. Verify Dev Drive protection in Windows Security, then rerun the same build and trace. Keep the change if the measurements justify it.

← All articles