JetBrains revealed that the slow startup reported by Rider and ReSharper users on Windows was not entirely caused by the tools’ architecture, but was largely related to scans performed by Microsoft Defender when they launched. According to the company’s findings, Defender added tens of seconds to the first launch when ReSharper ran as a separate process outside Visual Studio, while other tools completed their scans in less than a second.
This finding followed ReSharper’s adoption of an Out-of-Process (OOP) architecture, which JetBrains developed to address ReSharper’s impact on Visual Studio responsiveness. The company released OOP to the public the previous year, and it became enabled by default in ReSharper 2026.2.1. While internal measurements showed an overall performance improvement, user reports began pointing to slower startup, prompting JetBrains to conduct a more detailed analysis.
Where did the delay appear?
JetBrains focused on Microsoft Defender trace logs through ETW, or Event Tracing for Windows, as well as direct measurements of processor time. The company used events from the Microsoft-Antimalware-Engine provider, particularly StreamScanRequestTask events, which record the beginning and end of each scan operation.
The data showed that files located in write-protected paths receive trust rules that cause Defender to handle them more lightly during startup. However, when ReSharper began running as a separate process, it underwent a full scan, including DLL libraries loaded from the user’s installation folder. As a result, scan time rose from approximately a few seconds to tens of seconds in some cases.
JetBrains analyzed dozens of development tools and found significant differences among them. Cold-scan times for JetBrains environments and other editor-class tools ranged from approximately 10 to 40 seconds, while they remained below one second for Microsoft environments and other editing tools in the same test. Command-line-based tools took approximately less than two seconds, which the company attributed to their small executables and limited number of DLL libraries.
Testing and collaboration with Microsoft
The measurements were conducted on a Dell Pro Max 16 (MA16250) computer with an Intel Core Ultra 9 285H processor featuring 16 cores and 64 gigabytes of DDR5 memory, running Windows 11 Pro. The tools were run inside a Hyper-V virtual machine configured with eight vCPUs and 8 gigabytes of fixed memory. JetBrains measured each tool ten times, rebooting the virtual machine before every attempt to simulate a cold start and reduce the impact of file and memory caching.
JetBrains was initially unable to explain all the scanning rules, even after reviewing the available documentation, so it contacted Microsoft’s team. The collaboration helped identify the factors that caused Defender to perform more work, and also helped explain why Rider underwent more intensive scanning than IntelliJ IDEA and ReSharper combined.
Microsoft issued changes to Defender in version 1.449.454.0 to address the specific case of Rider and ReSharper OOP when they are installed inside a write-protected folder. However, JetBrains Toolbox is installed by default at %LOCALAPPDATA%\Programs, a path that permits writing without elevated privileges, and therefore does not benefit from the improvement associated with protected folders. JetBrains says it is still evaluating the best way to handle Rider installations through Toolbox and Microsoft Defender exclusions.
A tool for measuring Defender’s impact
JetBrains released the Defender Performance Tool to help developers and publishers conduct the same investigation. The tool makes it possible to monitor scanning activity in real time while an application starts, plugins load, or a compilation operation runs. It also allows previously recorded captures made with New-MpPerformanceRecording to be opened and analyzed later, and CSV data to be exported when working with multiple captures.
JetBrains notes that adding local exclusions to Microsoft Defender may be prohibited by system administrators in managed environments. Therefore, it does not present this step as an option that is always available, and it should not be treated as an automatic alternative to understanding the cause of the slowdown or to complying with enterprise security policies.
What changes in practice for developers?
This case shows that measuring development-environment performance is not limited to application execution time or memory consumption within the tool itself. The delay may appear in a security layer operating alongside the program, and its impact varies according to the installation method, the location of the files, and the number of libraries loaded at startup.
JetBrains recommends keeping Microsoft Defender definitions up to date, using the PowerShell module for Defender performance investigations, and trying the new measurement tool when unexplained slowness is observed. It also mentions installing programs in write-protected folders, using the Add-MpPreference command to configure an exclusion when necessary, and creating a Dev Drive to store repositories and package caches.
Editorial reading: The most important change is not merely an internal improvement in Rider or ReSharper, but the discovery of an unclear interaction between the design of the development tool and the security-scanning mechanism. Nevertheless, the results remain tied to a specific test environment, a virtual machine, and a limited number of measurements; therefore, they do not prove that every Windows user will experience the same difference. The practical value of the article lies in providing a method and a tool for verifying the cause before modifying security settings, while the question of support for JetBrains Toolbox installations and the restrictions imposed by system administrators remains open.