Build1 publisher3 min readPublished
ReSharper lost Defender's path-based trust the moment it became its own process
A refactor that moved no logic changed how Microsoft Defender treats the binary, because the trust rules follow the install path. JetBrains published the ETW harness, so the cost is measurable on your own machines.
The Engineer · Build desk
What happened
- JetBrains profiled the startup regression that followed ReSharper's out-of-process launch and found the latency came from Microsoft Defender scanning the new process for longer than expected.
- Reading Defender ETW logs across dozens of developer tools, JetBrains found startup scan times ranging from under a second to more than 30 seconds.
- Each tool was measured 10 times inside a Hyper-V VM, rebooted before every run to force a cold start and strip file and memory caching.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A process boundary is also a policy boundary now. Any team pulling a component out of a trusted host binary has to expect to re-earn that trust from the endpoint scanner, with no code change to point at.
- decision Install location turns into an architecture decision. Putting the child process in a write-protected directory buys trust rules that a per-user directory does not.
- capability Arguments about whether the endpoint agent is slow can be settled in elapsed seconds using Microsoft's own provider, on the arguing team's own hardware, instead of by anecdote.
- cost Aggregate telemetry read the OOP change as an improvement while users were paying the startup bill, so a metric that averages sessions will not price a first launch.
Defender's trust decision attaches to the image on disk, not to the work the code does. A plugin loaded into a host binary that sits in a write-protected directory inherits that host's wider trust rules, which is why JetBrains measured only a couple of seconds of scan time while ReSharper's DLLs were still being loaded from the user installation directory [4]. Give the same code its own process and the engine judges it on its own merits, from a path the user can write to, and the full scan arrives at first launch [5]. The refactor moved no logic; it changed which executable the antimalware engine was asked to evaluate. And the refactor had a good reason: performance was the top subject of user feedback, and ReSharper's in-process effect on Visual Studio responsiveness is what pushed JetBrains to the out-of-process design in the first place [17].
The 10 to 40 second band JetBrains reports for its IDEs and other editor-class tools is a cold-start figure by construction [13]. The workload ran inside a Hyper-V VM with 8 vCPUs and 8 GB of static RAM, hosted on a Core Ultra 9 285H laptop with 64 GB of memory under Windows 11 Pro [10]. Ten runs per tool, VM rebooted before each one to strip file and memory caching [11]. Rebooting between runs is the correct call for isolating a first scan, and it also means none of these numbers describe a warm second launch; JetBrains itself frames the penalty as landing on first launch [5]. Ten reboots per tool across dozens of tools is a harness whose runtime is mostly Windows booting.
Against the couple of seconds the in-process configuration cost, the out-of-process band works out to roughly 5x to 20x, reading "a couple" as two [16]. For that ratio to describe your fleet, your tool has to install into a user-writable path, and your endpoint policy has to scan that path the way this VM did. Change either and the number is not yours.
The reproduction path is the more portable deliverable. Defender emits scan events under the Microsoft-Antimalware-Engine provider, and Microsoft ships a PowerShell module for these investigations: New-MpPerformanceRecording to collect a trace, Get-MpPerformanceReport to analyse it [8]. The StreamScanRequestTask events carry a Start and End per scanned stream, which is elapsed wall time rather than CPU time [9]. JetBrains also took direct CPU time measurements and reports the two roughly equivalent for its scenario [7]. Those are not the same quantity in general, so treat the equivalence as scoped to the workload it was tested on. The tool JetBrains published lets other teams run the same investigation, with the distinction written up in its GitHub readme [14].
Out-of-process mode is on by default as of 2026.2.1, which JetBrains attributes to these investigations, and the account credits Microsoft's explanations and help along the way [3][15]. What got cheap here is the diagnosis. If you ship into a per-user directory and you are weighing a child-process split, the cold-scan bill is now something you can measure before the startup complaints arrive.
What to watch
- Whether the published tool reproduces the 10 to 40 second band on physical developer machines rather than an 8 GB Hyper-V VM.
- Whether Microsoft documents the wider trust rules for write-protected paths, or they stay behaviour inferred from ETW traces.
- Whether other vendors shipping into per-user install directories publish their own Defender scan numbers using the same harness.