Fix Windows Defender issues #9
Comments
|
Any progress here? Eclipse IDE is deadly slow on Windows with virus scanner active. |
|
+1 Excluding my Eclipse folder and workspace from Windows Defender gives me a massive speed boost for Eclipse startup time. |
I'm waiting for the first maleware that aims at eclipse installation folders in the hope they are excluded from anti-virus/maleware scans... 👎 |
|
Re eclipse-platform/eclipse.platform.swt#10 (comment) I started to write the following, but I later decided to keep the request focused on the tree selection issue:
One can easily see here that more time is spent "scanning" than in the actual process doing real work. And all the scanning seems to happen in the installer when creating the new installation and then each and every time any installation is launched.... Given this issue is now link to the tree selection issue, perhaps the powers that be looking at either issue will see both issues... |
|
IntelliJ suffers too. It has automatic detection for Windows Defender and offers to exclude directories: |
|
Using Plugin info: https://www.mojohaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html The jar files are already downloaded on the computer - why do they need to be scanned when they are copied from one location to another on the same computer which downloaded them? Setting an exclusion for *.jar files has significantly sped it up. Edit: This is happening on Mac. |
|
cc @stephenrwalli can you help to address this, this makes the Eclipse IDE very slow on Windows. |
|
CC @brunoborges and @gdams - I know we've been able to talk to the Defender Team about this before and it's a bit of whack-a-mole with getting exceptions and then newer versions perhaps overriding that. Can we engage on a more permanent fix? |
|
There is an ongoing effort about this, in general. Not just for Java. Defender design impacts all developer tools and languages. I don't have more info to share at the moment, though. But rest assured, Windows team is looking into this. |
|
Any chance for an end-of-year Defender team update? |
|
@brunoborges Hi Bruno. In July last year you said that the Windows team is looking into this. Can you tell the java development community:
|
|
Hey @marioja , thanks for pinging me here. I will meet with the Windows team in the coming weeks and I'll bring this topic up again witblh them. Stay tuned! |
|
Just to mention it from my duplicate report, it’s not only an issue with defender, in fact other malware scanners are partially even worse (MS can’t fix them but at least influence with certification criterias). Some of the issues I observed with trendmicro:
|
|
@ecki You found my report, this is truly a pain. |
I see you ,) but more seriously, I just noticed your report is probably only related to dirty buffers on windows, not the busy Filmhandle by malware scanners (but I have seen those effects, too) |
|
@michael-o have you noticed this issue impacting some of the Apache big data projects? |
I am not involved in Big Data, in Maven only. |
|
@michael-o would you have a chance to suggest a Maven project we can investigate to track the performance? |
|
We are being hit by this running tomcat on windows server. The first page load is excruciatingly slow because of defender scanning all jars on open. I'm sure the team has already thought about this and it's not that simple (it never is), but all jars on maven central are supposed to be signed. Could it be somehow possible to trust those signature which are easy to untrust with a definition update? That would reduce the amount of full jar scan to a minimum since I'd guess 80% of jars to scan come from maven central. Here is an excerpt from a trace I ran during a cpu spike, tomcat jars are pretty clear offenders: |
|
The maven signatures are unfortunatelly detached, you don’t have them in the jar (and using jar signing would be possible but is frowned upon). in case of antivirus it would be an option to scan files only when they are written and then attach a signature/version information (NTFS stream or extended attributes) so you can verify the local filesystem is unaltered and the scan was with an up-to-date scanner. In case of new malware signatures the background scanner could refresh those markers. |
None in particular. |
|
Please, do provide us with the millions required to run a municipality and I'll happily be able to chose what OS I run my software on. Otherwise, maybe refrain from derailing the conversation into wasted heat. |
I wasn't able to hold my self off. But honestly, this has been open now for almost three years. Do you really expect anything to happen here? |
|
@michael-o do not give up, just read that in the news: |
If you want to publish some numbers Apache KAraf OSGi is reasonbable big and still pretty selfcontained. We use that internally as a benchmark quite often (but then again, we depend on it). |
Sounds like a totally convoluted solution to a simple problem: Don't scan. |
Well yes, but for those who dont want to scan the solution is easy: dont scan :) |
The scanning should be transparent. Experienced developers will always have the option to disable scanning (unless forbidden by IT Corp rules). But for others, it is better to leverage the Dev Home experience. Faster and yet still secure. |
How does this solve the problem? |
|
IMHO, the development mode doesn't solve the reported problem. It is not a problem for developers, but a problem when running Java programs. It is a generic end-user problem and it only affects developers because they happen to be heavy end-users. The problem is that Windows Defender doesn't trust jar-files. Therefore, it scans the full content of a jar-file upon access. This takes a lot of time and resources (battery drain). On top of that, scan results are not cached, which results that this scanning overheard is observed each time a application starts. This results in poor performance of every Java application on a platform with Windows Defender running. Apparently, the problem and its impact is not understood by Microsoft. The issue is affecting thousands of applications, millions of people and takes many hours of productive time. |
|
Defender doesn't trust any ZIP file. A JAR file is a ZIP file, and WD will treat as such. I am not sure about scanning results being scanned, though. Sure that would help. |
I understand that argument, however, as @rolfth pointed out, signatures could help WD distinguish between a simple ZIP file and a potentially more trustworthy signed JAR file. |
|
I would not waste time with jar signatures, they are very uncommon (and you can as usual easily sign malware as well). Not to mention that signature checking is slow as well. |
Depends on which report :) the initial report in this ticket is about IDE and Build systems, for that development mode with trusted filesystem helps (for those who can use it), for the also mentioned application startup issues it won’t help - but those are less severe imho. |
Yes, this ticket is reports the effect on development efficiency. However, it starts with a generic statement. Also it references to the original issue that I reported on Microsoft Feedback Hub, which is generic for Java applications too. |
I'm old enough to remember NGSCB, Palladium, Trustworthy Computing where Microsoft argued signed code = safe. |
Hello, thanks for creating this repository! 👋🏻
Describe the bug
Eclipse, IntelliJ and other Java programs are significantly slowed down by Windows Defender. This makes Java development on Windows difficult: for example, an IDE may take several minutes to launch compared to a few seconds on other operating systems.
This issue was originally reported on the Microsoft Feedback Hub and initially received many upvotes, even though the voting system has since then been removed from the hub. Here's the full report written by Rolf T:
To Reproduce
Install and launch Eclipse, IntelliJ or other Java programs on Windows.
Expected behavior
Windows Defender should not slow down Java programs, especially if these are signed properly.
Additional context
Some programs provide utilities to automatically add themselves to the Windows Defender exclusion lists and tamper with the antivirus's settings. This feels wrong and makes the Java ecosystem on Windows less secure.
The text was updated successfully, but these errors were encountered: