-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AdoptOpenJDK - Download hangs on windows on 4/30/2019 (Edge & Chrome verified, multiple machines) #477
Comments
@tcarlisle2012 Can you tell us which version of Windows you are using and the exact binary that you were trying to download? |
Sorry I put this in the wrong section. Both systems are running version 1809. With different build numbers. One is build 17763.348 and the other is 17763.427. I was originally trying to download OpenJDK11U-jdk_x64_windows_hotspot_11.0.3_7.msi, but then tried the .zip, then tried the 1.8LTS, and all do the same. |
Testing from a volunteer: OpenJDK11U-jdk_x64_windows_hotspot_11.0.3_7.msi with Edge on a yesterday installed Windows 10 1809 with all patches downloaded without issues. It took the malware scanner some time, but it finished. Testing from a volunteer: The JDK 8 MSI just finished, too. |
Have you perhaps got the Windows Defender settings higher than the default? |
No, Windows defender settings were set to the usual and unmodified. Of course, when I disable real-time protection, it then works, but that defeats the purpose. It doesnt matter if cloud based or auto sample submission options are o or off, it hangs as long as real time protection is enabled, and works when that is disabled. Another option, is to install a 3rd party like Avira, and then that product takes the front seat for real time protection. I installed Avira and verified no issue. But for people running windows defender as their primary real time protection might report issues with this site. Never had any other sites do something like this. Of course, if it scanned and failed that would give us something to work with, but it just hangs. Normally, when a download completes it gives a spinning indication that scanning is happening. That doesn't happen at all in the broken state. It just never even begins, as best I can tell. |
I've seen long running times for the scan, but it has always (eventually) finished. It may take minutes, but it does finish. |
I'm unable to replicate a hang on my Windows 10 (via Virtual Box) either - Install was fine and it checked the London Jamocha Community Certificate. @tcarlisle2012 Are you able to grab any Windows install / MSI / system logs? |
Ok, I think I've narrowed it. But first, is everyone chiming in using nothing but windows defender? Because if not then it really isn't comparing apples to apples. Using my test system, which only has windows defender, i moved the file to another web server and same thing. So we can rule out the web site or code. Looking further, if I right click the file (happens to be the zip file of your latest jdk11 x64 w/hotspot build) and choose to scan with Windows Defender, it scans indefinately. However, since I can see its status via the security settings front end, it is counting total files up in the 60,000 range now, and it is going to just keep going. Something about the archive is causing it to loop indefinitely in a scan by Windows Defender. Scanning with Avira on another system it finishes and counts the right number of files (604) and folders (131). Ok, while writing this, the windows defender scan of the extracted files did finish, counting a total of over 77,000 files. That can't be right, because there are not that many files extracted. Something is sending it into circles. Looking further, individually scanning each directory under the extratced jdk1.11.03 directory, they all complete in reasonable amounts of time, except the jmod directory takes about 15 minutes and counts thousands of files, yet there are only 71 files in that directory. So the bottom line is windows defender scanning is going in circles scanning the jmods directory. I have a feeling avira skips it altogether. Windows defender is probably providing better security posture, as scanning jmods is probably the right thing to do. But it should not scan in circles. Or perhaps it should.... I am not the expert in java > 1.8 and perhaps jmods call other jmods? If so, following that recursion is the right thing to do, but perhaps windows defender should track ones it already scanned. In any event, it is looking like a windows defender + jmod scanning issue and not a web site issue. I did kick off a download of that built zip file (from the system running only windows defender) and am going to let it run until (or if) it finishes -- hours if that is what it takes. I will report the results here when that happens. On a side note, it looks like the files end up in the "downloads" directory as soon as they are done downloading, and before windows defender finishes its thing. But chrome & edge don't recognize it as complete until windows defender finishes. I mention this becuase people that are being held up with productivity because of this, since you are fairly sure the files are not malicious (you did check sha256 values, right?) you can continue working. |
I was just using Windows Defender yes. If it's scanning each class file I could see why it gets into thousands of files. I'm pinging my contact at MSFT to see if they can help here. |
If defender is recursively scanning jmod files (which are very much like zip files), then the count should be higher, but I'd expect something closer to double the number of files, not 100 times as many. |
And if it scans the 'modules' file the count would be much higher (it contains >27,000 resources in a Linux x64 build). |
Good news, the system still running only windows defender did ultimately finish scanning the file after about 30 minutes. That system is way underpowered for the workload, but is the only one I have left without a third party security suite. But still, one would expect a downloaded msi or zip file to not take more than a few seconds. Bottom line, windows defender takes a lot longer because the archive contains jmods, and windows defender doesn't return success and control back to the browser until that is done, versus avira does and continues scanning in the background (and skips the jmods probably by default). I just saw the same downloading a build from jdk.java.net, so I am more than comfortable closing this and considering it an issue of "windows defender takes a very long time to scan JDK's" |
Great thank you. |
I confirm I have already seen same behaviour ( long long scan by windows defender ) for Oracle JDK. |
Going to reopen this and get MSFT folks to comment |
Just ran into this bug... Interestingly enough, I have a project about 1/3 the size with quite a few class files as well as the entire Java FX runtime bundled and it takes seconds. In my case, the project that does NOT suffer this issue is packaged as an EXE installer (not a MSI installer like AdoptOpenJDK). Not sure if that information helps. I can't imagine Microsoft would be OK with its OS spending 30 minutes scanning -- for example -- the .NET framework... this seems like something they'd be willing to help fix, assuming there's a proper escalation path. |
Just to provide info, I was downloading the zipped JDK, not the installer version. Also, I have downloaded JDK from Oracles site and got the same issue. So I am fairly confident this is an issue with Windows Defender and how it handles java .MOD files. I would venture a guess that third party AV solutions, like Avira that I used to use, obtain better performance by not scanning java classes recursively. Clearly that would result in a lower security posture. Or, cloud based security features handle it by only scanning the file from the download source the first time the cloud sees that file signature, and upon determining it clean after that point the AV considers it trusted and other users are spared the scan. That would be better than skipping java archives altogether, but still be less secure than 100% scanning. I have gotten into the practice if turning Defender off when downloading a java archive from a reputable source. |
@karianna says MSFT is a sponsor to the AdoptOpenJDK project, so they're best to help with this. This may be anecdotal, but Firefox didn't seem to trigger the 30-minute download/scan/delay issue, so that may be a stop-gap for users in addition to modifying the Windows Defender scan settings. |
I got the same problem with the "OpenJDK11U-jdk_x64_windows_hotspot_11.0.3_7.msi" file. I'm trying to fetch it with Firefox to see if I get another result (as tresf stated) |
Any decent browser is going to toss the file to Windows AV, which will toss
it to a 3rd party AV if installed -- and the same issue will take place.
You will notice the same behavior if you go to oracle's site and download a
zipped JDK from them, and most likely any java archive. I've searched
google for issues similar and people report this behavior with many
different types of zipped files -- like MalwareBtyes application.
There really is only one what to speed it up, which would be to have it not
dive into each file and each call to other files recursively... or to trust
the file completely and not scan it or scan it lightly to make sure its
contents do match up with a signature of a version that has been deemed
safe. One would think that the cloud based features in Windows Defender
would be doing exactly this, but apparently not. The 3rd party solutions
probably are doing a much, much better job at this.
Since they don't provide a way of turning off this recursion, your only
options (if you don't want to move to a 3rd party solution) are to exclude
a directory or a process or turn off real-time altogether (temporarily).
The problem with exclusions is that if you exclude your downloads directory
or the browser process, that is really the main point of ingress where
nasty code will come in from the external world. I am more comfortable
recommending to turn off real-time protection when downloading a file that
is problematic this way which you are comfortable trusting.
Or just wait. I suppose that is an option. It takes about 20 minutes on up
depending on the system. MS Defender is not designed to take all compute
resource available in order to expedite, because if it did the performance
footprint would be way to high and no one would use it. It seems to max out
at about 25% of my CPU on a modern Core-I7 and it never pushes disk IO
anywhere near 100%. Hence by design it is throttled and hence these scans
take a long time.
…On Sat, May 18, 2019 at 4:23 AM gravi ***@***.***> wrote:
I got the same problem with the
"OpenJDK11U-jdk_x64_windows_hotspot_11.0.3_7.msi" file.
Well, I think... The download process hung at the end of the file-fetch.
(I didn't verify if it was due to some antivirus scan).
I'm trying to fetch it with Firefox to see if I get another result (as
tresf stated)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#477?email_source=notifications&email_token=ABY34OEZETQ3EG4H7BCYB2DPV64H5A5CNFSM4HJN4MWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWKGII#issuecomment-493658913>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABY34OE26KYTS3G4Z546XPLPV64H5ANCNFSM4HJN4MWA>
.
|
Tested with McAfee -- for some reason when downloading with Chrome or Edge the default behavior is to NOT iterate through
Just reiterating that Firefox doesn't. :D |
They do indeed.
There is no difference between a release and nightly build in terms of codesigning. |
Hmm, in that case, I can only imagine whitelisting and/or a difference in the windows defender version on people's machines (although I'd expect most techies to aggressively upgrade that component). |
Windows 10 + Chrome and definition update : KB2267602: 1.297.1299.0 from today and analysis still running after 1 hour for OpenJDK12U-jdk_x86-32_windows_hotspot_12.0.1_12.msi It can't be a signer whitlist ... and as people complain about scanning time for zip file ( wich is not signed ) event whitelisting our cert will not be sufficient |
Thought me and my teammates where the only people facing this problem... Most archive downloads of significant size (>100m) via Chrome are blocking for us. No way out, yet, but using FF for those kind of downloads :-/ So I would say this issue is definitely not specific to your AdoptOpenJDK archive. Addition: |
The latest signed build downloads and installs without issue. However when I attempt to delete the installer file (Shift + Del) the problem resurfaces with it taking forever to calculate how long to delete. I have to reboot to make progress. |
Having the same issue with Microsoft Edge 44.17763.1.0 / Chrome 75.0.3770.142. The JDK file Incidentally there is no issue when using Firefox. |
Hi all, FYI - Windows defender is due another update in the next 24-48 hours and then a larger fix will occur in August. |
Seeing same issue downloading OpenJDK 12 on Microsoft Edge 44.18362.1.0. After downloading scanning continued for over an hour before I terminated the operation. Downloaded and saved fine with Firefox and ran with Windows Installer. It took about 10 minutes before I got the dialog that OpenJDK was asking permission to install itself and then another 5m to complete. Installing OpenJDK 11 took only about 5m total. Installing OpenJDK 8 took about 2m total (after downloading). |
@karianna I just tested freshly generated Windows 10 1903 images. All results with Edge, no third-party AV: JDK 8u222b10 MSI all complete within 4 to 5 minutes on a machine with 4 CPUs and 16 GB RAM. |
Thanks for confirming! Can others check (please make sure your O/S, Windows defender, and browser are at the latest versions. |
Crazy-long scan now on two different machines, but it does eventually complete. I've not encountered an indefinite hang yet (although I did nearly give up on the second one). Definitely the longest scan I've seen on pretty much anything. It seems that the browser has a single thread dedicated to download management, because it blocks that and stops anything else being downloaded in the meantime, but that's a bug for someone else! Windows Version 10.0.18362 Build 18362 |
33 minutes to scan AdoptOpenJDK JDK 11.0.4.
... and this is the official installer. I consider 33 minutes to be unacceptable for the average end-user. I would expect 5 minutes to be on the high-side of acceptable user experience. Machine tested on is HP Spectre 16GB RAM, Intel i7 Quad Core (8 logical processors). Updates were last run today, checked manually and installed. |
I'm now working for Microsoft :-). I'm going to find the right team and track this down. |
I've found the correct folks. The update still needs to be rolled out to 100% of windows users. I'll check back here in a week |
FYI, Defender is coming to Linux, so the problem may cascade to other platforms if the factors which influence this are common between AV engines/archives https://www.zdnet.com/article/microsoft-defender-atp-is-coming-to-linux-in-2020/ |
@tcarlisle2012 Have you had a chance to try again recently? |
I've been working with AdopOpenJDK on Windows right along and I had completely forgotten this bug, suggesting it has been fixed. Today specifically, I installed 11.0.6, 8.0.242 (both JDK and JRE) and no endless wait times. I have a feeling that the bug will rear its ugly head again someday in the future, but the MSIs don't seem to be having issues any more. 🤞 |
@tresf Thanks for confirming. If the problem comes back, please do not hesitate to reopen. |
Issues have been reported with the new codesign cert. Sounds like it needs to be whitelisted by the defender team |
Hi, C:\Program Files (x86)\Horus_269\jre18282\bin>C:\Users\jmichler\Downloads\Sigcheck\sigcheck64.exe -a java.exe Sigcheck v2.80 - File version and signature viewer C:\Program Files (x86)\Horus_269\jre18282\bin\java.exe: I'm having this for an app based on eclipse RCP; maybe it is only then? See also https://answers.microsoft.com/en-us/windows/forum/windows_10-security/first-start-of-eclipse-rich-client-based/42ada574-acba-49e2-b1ad-0f585b747fa3?tm=1618590387660 |
please raise this at gihub.com/adoptium if it is still an issue. |
There is something about your binaries downloads that hangs Windows antimalware service executable. The downloads finish transferring data, but then the browser kicks it over to antimalware service executable to scan, which consumes CPU or GPU indefinitely and never returns. Once this happens, user cannot download files from other sites either because this keeps the antimlaware service executable hung.
No other downloads from other sites do this. Verified on multiple PCs and multiple browsers.
The text was updated successfully, but these errors were encountered: