Chrome Download hold up by Antimalware Service Executable

I found that whenever I finishing download tar.gz or tar.xz files (100-200MB), CPU usage of Antimalware Service Executable will go up to 100% and all other downloads will be hold up for a long time. I guess it's trying to extract and scan all files inside.

I tried to workaround it by adding the extensions to "Exclusion" and it doesn't hold up anymore but seems it's not a good solution.


|
Answer
Answer

As I stated in my earlier post Justy, it's also a side effect of the efficiency or lack thereof for each of the individual apps you've installed to handle those particular file type associations in Windows.

Though the unpacking of an individual compressed file may seem to happen quickly, it's when either a large number of files or many different individual packed files are handled at once that the inefficiencies within these decompression apps will display.  So though any free unpacker may work in order to complete the task, a small inefficiency in any of them will be amplified as the number and size of these files increases.

This fits your own belief very well, since a complex combination of many of these files embedded within each other just exposes these inefficiencies far moe quickly.

This is why I don't personally install an optional handler for zip and other native file associations, since those built into Windows itself are likely to be most efficient and also not cause significant overhead for Windows Defender's real-time scanning, since these operating system components are all fully aware of each other.

tar, gzip and other non-native 3rd-party compression systems are often abused by attackers attempting to install malware, so they're also likely to be closely monitored and examined for potential malicious activity by Defender as a result, creating inherently greater overhead than those native to Windows.

Rob

9 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Answer
Answer

Justy,

Since I haven't developed code in years and never using Java, I'm not familiar with the JDK packages since I've also personally avoided its plug-in installation within my browsers for many years.

I'd also not thought about the fact that the Windows 8.1 system on which I was reviewing the files associations might not include all of the same file types supported with Windows 10 and I still haven't taken the time to confirm that, as I don't think it's important to your primary issue.

bhringer's mention of emulation is something I didn't think to call out, but when executable code of any sort isn't digitally signed today in Windows, this is something that can have a significant effect as Defender tries to identify and confirm the safety of each individual executable component in a package.

The other item I'd note is that when I took a look at the current Java SE Development Kit 11 Downloads from Oracle, the gz packages provided are intended for the Linux, macOS or Solaris SPARC platforms, while the Windows packages are either exe or zip.  Though these still aren't signed, the fact that gz packages aren't native file types in Windows means they'd be looked at with some suspicion by Defender.

Note that when I state native file types, I don't mean they don't exist, only that they aren't file types that Windows has traditionally used in its own operation, so regardless of whether support for these has been added in Windows 10, it's unlikely to have been optimized as fully as the more historically supported types such as exe or zip.

Since the packages aren't digitally signed, Defender has no way to insure they haven't been tampered with, so it must individually extract, scan and in some cases emulate every piece of executable code, since without a signature there's no way to guarantee the packages are intact or indeed what the individual modules might actually do.

All developers are impacted by these issues to some extent while developing new code, while those using development environments not native to Windows are even more likely to experience the side effects of Defender going into overdrive.  As a cross-platform development environment, the JDK trades the benefit of that multiple platform support for the necessity of extreme scrutiny on a general purpose operating system with the popularity of Windows.

What most fail to recognize is that the built-in Windows Defender was developed as default protection for the consumer and business customers of Windows, while it's less concerned with the effects on developers whom are typically more knowledgeable and security conscious.

Rob

8 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

 
 

Question Info


Last updated August 27, 2020 Views 2,163 Applies to: