Why Rider and ReSharper Were Slow to Start, and How Microsoft Helped Fix the Problem

.NET Tools ReSharper Platform Rider

When we launched ReSharper’s out-of-process (OOP) architecture, users reported slower startup times for IDEs using ReSharper on Windows. After profiling, the cause surprised us: Microsoft Defender was scanning our process for longer than we expected. This post is about what we found, what we learned working with Microsoft, and a tool we built that allows others to run the same investigation.

An unexpected factor in startup performance

Performance of our tools has consistently been the number one subject of feedback we’ve received from our users over the years. Our telemetry and user surveys confirmed what many of you have been telling us: Despite ReSharper’s powerful features, the impact on Visual Studio’s responsiveness was affecting your daily workflow. This led us down the path of developing our new out-of-process (OOP) architecture. We originally launched OOP mode for the public last year. (Now, thanks to these investigations, as of 2026.2.1 it is enabled by default.) In general, our telemetry indicated improved performance. However, at some point, we noticed something unexpected – customers started reporting slower startup times. After a few profiling iterations, the collected data pointed to an unexpected source of latency: Microsoft Defender.

It turned out that processes in write-protected paths receive wider trust rules. Microsoft Defender barely touches those processes during startup – scanning takes a couple of seconds, even when ReSharper loads their DLLs from the user installation directory. But the moment ReSharper started running as a separate process, Defender scanned it in full, adding tens of seconds to first launch (see the chart below).

This triggered our curiosity and sent us down a rabbit hole. We started analyzing Microsoft Defender ETW (Event Tracing for Windows) logs across dozens of developer tools, and the findings were striking: Some tools get scanned for 30+ seconds at startup while others finish in under a second, as we had observed above. We obviously wanted to learn the reasons behind that and find ways to speed up startup for JetBrains tools. An ambitious project, but we were up for the challenge!

The first thing we needed was to set up a repeatable measurement process. That way we could share it with other teams in JetBrains, and with our colleagues from Microsoft to have a productive conversation. We are grateful for all Microsoft’s explanations, openness, and willingness to help us with this investigation.

Measuring the impact

We tracked the activity of Microsoft Defender in two ways: Microsoft Defender ETW logs (as mentioned above) and direct CPU time measurements. We found the two methods to be roughly equivalent for our scenario. If you’re interested in the distinction, see our GitHub readme for more info.

Microsoft Defender, like many other Windows components, uses ETW. It emits events under the Microsoft-Antimalware-Engine provider. Microsoft provides a PowerShell module for Defender-related performance investigations that uses this provider. It has two cmdlets: New-MpPerformanceRecording to collect a trace, and Get-MpPerformanceReport to analyze it.

In our scenarios, most slowdowns came from Microsoft Defender’s scan events. The Microsoft-Antimalware-Engine/StreamScanRequestTask ETW events report each scan’s Start and End time, representing how long Defender spent scanning that stream in real-world elapsed time. The data we gathered showed us clearly how Defender was impacting our tool’s startup wall time.

Methodology

Performance measurements were run on a Dell Pro Max 16 (MA16250) laptop with an Intel Core Ultra 9 285H (16 cores) processor and 64 GB of DDR5-class memory. The host ran Windows 11 Pro. The workload was executed inside a Hyper-V VM configured with 8 vCPUs and 8 GB of static RAM. Each tool was measured 10 times.

As per standard best practices when measuring performance, we rebooted our VM before each measurement to simulate a cold start. This reduced observed file and memory caching effects on our results.

The charts below show the mean scan time with standard deviation error bars.

Results of the experiment

As you can see, we measured a variety of development tools, and there were clear differences in the amount of time Defender took to scan them: 

• JetBrains IDEs (JetBrains IDEs, and some other editor-class tools) took roughly 10–40 seconds to scan at cold start, while Microsoft IDEs and various other editors had negligible scan times in comparison (all under 1 second).
• CLI-based tools (the command-line agents) took under ~2 seconds to scan, likely because they’re small, simple binaries with few DLLs.

Collaboration with Microsoft and our solution

Even though we had built a tool to measure Microsoft Defender’s impact, we still failed to fully understand Defender’s scanning principles. We also consulted their documentation to no avail. So we reached out to our colleagues at Microsoft directly!

They helped us understand the parameters which cause Microsoft Defender to perform more work. A core principle was that files in write-protected folders would be optimized for scanning.

At this point, we reviewed all the ways we install and start our tools to find a way to reduce the scanning times. One observation was that JetBrains Rider is subject to even more intensive scanning than IntelliJ IDEA and ReSharper combined. The reason for this was also not clear to us, so we asked the Microsoft team for help again. They were able to make optimizations on their end for this specific case and adjustments to Defender released in version 1.449.454.0. Now ReSharper OOP and JetBrains Rider get the scanning performance boost when installed into a write-protected directory:

JetBrains Toolbox installs software in the %LOCALAPPDATA%\Programs directory. Since this directory does not require elevation for writing, Toolbox can update the software seamlessly, but as you can see in the chart above, it does not receive the write-protected performance boost. 

As we’ve reported previously, Rider itself excludes some directories from Microsoft Defender during the installation process (more about this here). It uses the Add-MpPreference PowerShell cmdlet to help you automatically configure a Microsoft Defender exclusion. We’re still evaluating the best way to support the JetBrains Toolbox installation of Rider and Microsoft Defender exclusions. You can follow our progress in our TBX-2851 issue.

Note: The ability to add exclusions locally can be disabled/blocked by administrators in managed environments. 

Measuring for your own tool

If you’re experiencing the slow startup of your own tool, it definitely makes sense to analyze whether Microsoft Defender is affecting it. To help with your investigation, we’re releasing the tool we built for our own – the small and easy-to-use Defender Performance Tool. The source code and release builds are on GitHub.

A few things you can do with it:

• Watch your application’s scan activity in real time as it starts, loads plugins, or compiles something.
• Open snapshots recorded offline with New-MpPerformanceRecording, so you can investigate traces from another machine (for example, one collected by a customer).
• Export a CSV file when multiple snapshots are loaded, for further analysis.

We hope that helps you with similar investigations. Let us know of any interesting findings!

Conclusion

As you can see, Microsoft Defender can have a large impact on tooling performance. We learned a lot working with Microsoft in this area, and we hope our findings help developers and vendors understand how best to maintain the security of their Windows systems by observing and tuning Microsoft Defender’s behavior.

Summary of best practices for working with Microsoft Defender:

• Keep your Microsoft Defender definitions up-to-date.
• Use the Microsoft PowerShell module for Defender-related performance investigations.
• Try our new tool to help analyze Microsoft Defender logs, available on GitHub.
• Optimize Microsoft Defender scanning by installing software to write-protected directories.
• Use the Add-MpPreference PowerShell cmdlet to help you automatically configure a Microsoft Defender exclusion, if required.
• Set up a DevDrive on your Windows machine for storing your repositories and package caches.

Hopefully, you’ve noticed these improvements to ReSharper and Rider in your workflow too! ReSharper 2026.2.1 now ships with OOP enabled by default. Try it out today!