Jump to content

Scan of c:\users\all users\package cache\* slow


Recommended Posts

Using ESET business, Endpoint Security version 10.0.245.0 installed on client machines running Windows 10 Pro.

I have policy that initiates local full scan on clients on Sunday.  Something has happened recently that has slowed this process down tremendously on some of the machines, including my own workstation. It is now going on 70 hours and incomplete.  I have watched the scan, and I am seeing it trudge along taking several minutes per file on .CABs and .MSIs etc., and while I know some of those are large files, the majority just seem to take inordinately long time to scan.  Scan of c:\users\all users\package cache\*  appears to be the culprit, but for all I know other directories are also an issue.

Are there any good ways to identify what is causing it to be so slow? Are there any suggestions for good exclusions that might help?  Is there some way to tell what might be conflicting with ESET?  Any suggestions would be helpful. Otherwise, I may skip weekly scans

Using ESET business, Endpoint Security version 10.0.245.0 installed on client machines running Windows 10 Pro.

I have policy that initiates local full scan on clients on Sunday.  Something has happened recently that has slowed this process down tremendously on some of the machines, including my own workstation. It is now going on 70 hours and incomplete.  I have watched the scan, and I am seeing it trudge along taking several minutes per file on .CABs and .MSIs etc., and while I know some of those are large files, the majority just seem to take inordinately long time to scan.   Other machines do a full in-depth scan in 1-2 hours.

Are there any good ways to identify what is causing it to be so slow? Are there any suggestions for good exclusions that might help?  Is there some way to tell what might be conflicting with ESET?  Any suggestions would be helpful. 

(Also, I looked at KB2936, but it seems to apply to Home version and "Log all objects" is currently disabled. Should I just send in a log file to support at this point?)

 

Link to comment
Share on other sites

23 minutes ago, Carl Seiler said:

Using ESET business, Endpoint Security version 10.0.245.0 installed on client machines running Windows 10 Pro.

I have policy that initiates local full scan on clients on Sunday.  Something has happened recently that has slowed this process down tremendously on some of the machines, including my own workstation. It is now going on 70 hours and incomplete.  I have watched the scan, and I am seeing it trudge along taking several minutes per file on .CABs and .MSIs etc., and while I know some of those are large files, the majority just seem to take inordinately long time to scan.   Other machines do a full in-depth scan in 1-2 hours.

Are there any good ways to identify what is causing it to be so slow? Are there any suggestions for good exclusions that might help?  Is there some way to tell what might be conflicting with ESET?  Any suggestions would be helpful. 

(Also, I looked at KB2936, but it seems to apply to Home version and "Log all objects" is currently disabled. Should I just send in a log file to support at this point?)

 

Boy, I sure mangled that in editing.  Read the "second" one.

Link to comment
Share on other sites

  • Administrators

Please scan folder by folder to narrow it down to those that take long to scan. Then try scanning them with archives and possibly also with SFX archives disabled to see if it makes a big difference. Make sure to make these changes to the scan profile that is used in the scheduled scan.

image.png

Link to comment
Share on other sites

Thanks, Marcos.  Haven't done anything yet, but sat there and watched it.  It has now moved on and is scanning the chocolatey directory, and I sat and watched as it spent several minutes scanning a 66k C:\Users\All Users\chocolatey\lib-bad\Cmder\Cmder.nupkg which is a Nuget package.  It went along and dit he same thing on ..\lib-bkp\vlc\vlc.nupkg which is only 77k.  

I cannot change any of the settings pictured (I surmise I have to change those settings in the policy in ESMC?).  Anyway, Archives is currently set to off.  Self-extracting archives is set to on.

So, I scanned one of the subdirectories--the chocolatey package directory--without changing any settings, and I got 518 objects scanned in 3 seconds.  That seemed pretty fast.  

I then scanned the installer cache in All Users directory mentioned in OP.  It is clearly bogging down, particularly on .MSI and .CAB files.  In total it took 47 minutes to scan that subdirectory, not great, but not as slow as it was earlier today, when at times it was taking several minutes per file.

I then went into settings in the policie in ESMC/ERA.  I turned off self-extracting archives under ThreatSense (as I said, Archives was already set to off), and the same directory went to 14 minutes.

So, problematic directory reduced from 47min to 14min by turning off self-extracting archives in ThreatSense. The question I have is why does my computer take so much longer than the other devices?  Is it because I have more self-extracting archives compared to the other users?  Like are they just problematic for scanning in general?

Link to comment
Share on other sites

  • Administrators

MSI and CAB archives can be relatively big with hundreds or thousands of files inside which need to be extracted and scanned, needles to say that iso, img and other images are typically even much bigger.

If scanning a particular folder takes substantially longer on a machine but is faster on the others, check the following which may negatively affect the scan time:

1, the total number of files to scan
2, the type of files (standard exe/dll files or documents versus zip, rar,7z,... archives, msi, exe installers and iso, img,... images)
3, the size of archives and the number of files inside and their type (e.g. other rar/zip/msi archives in iso/img images).
4, the version of the installed archive module (new versions may bring support for new unpackers so archives that were not scanned previously will be unpacked and scanned)

8 hours ago, Carl Seiler said:

So, problematic directory reduced from 47min to 14min by turning off self-extracting archives in ThreatSense. The question I have is why does my computer take so much longer than the other devices?  Is it because I have more self-extracting archives compared to the other users?

Yes, that the most probable reason. You could create a listing (via dir command) of a same folder on two different machines where the scan time differs substantially so that we can see what files are there and their size.

8 hours ago, Carl Seiler said:

Like are they just problematic for scanning in general?

They are not problematic but files from archives must be extracted before scanning which is a resource intensive operation, especially in case of big archives and files inside. Generally the more archives you have and the bigger files are scanned, the longer it takes to scan them.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...