Download interferance/fail

we've been experiencing this for around 2 months now, and it's getting rather irritating.
i say 'we', i have 3 other people who have this issue, all on completely different computers.

the issue:
at around 99% download (a few hundred kb before 100%), ekrn.exe process takes 100% of a core. this happens on small 5mb downloads or 3gb+. the bigger the size, the longer it takes to finalise the download. also, it seems apparent that the download server(?) times out if the download is in this status for too long and thus the download will eventually fail on the bigger downloads.
i must point out that nod32 then proceeds todo it's usual 'scanning for viri' once the download reaches 100%.

machine specifics:
3x machines are all running intel cpu's (centrino duo, c2d, c2q), 4gb ram, win7 x64 RTM + latest updates. nod32 business x64 AV.

browsers affected:
IE8
Firefox 3.5.x & 3.6
Chrome (download and tested 5minutes ago)

tried fixes:
- disable nod32 completely - download completes as expected
- reinstalled nod32 and redownloaded .msi - problem still present
- enabled maximum file scan size in nod32 - this setting appears to have no effect and scans the downloads regardless.
- hosting apache on 'localhost', this would exclude ISP/router/internet/etc issues since it was "downloading" the file to another location of the same hard-drive. (ie: http://localhost/firefox3.6.exe, and save to desktop) - problems still present

can anyone help, or is this one for eset support?




edit 17/2/10 - edited for clarity

 

The Firefox installer contains 1390 files so it's normal that it takes about 30 seconds to decompress and scan each of the files. Do you have another example of a file that takes long to scan?

 

well, another one i've been testing on my work pc is the microsoft WAIK kit - http://www.microsoft.com/downloads/...65-9f76-4177-a811-39c26d3b3b34&displaylang=en, but thats a 1.4gb iso with even more files inside it...

the WAIK file usually times out at the 99% issue i mentioned.

just to re-highlight, when a download reaches 99%, the majority of the time it will pause. On the larger downloads it will generally timeout. This only happens when nod32 is active.it will THEN proceed to "scanning for virus's" once the file reached 100% download.

edit:
i dont know if it helps, windows file transfer, torrents and usenet downloads are all fine, although i guess thats due to the lack of a 'hook' feature where an AV can interject itself.

 

I tend to find most installation packages suffer in this way - as VeeHexx reports, the delay happens before the "scanning for viruses" step - is the file actually getting scanned twice?

(As an aside: presumably the file gets scanned as it hits the disk anyway, even if it wasn't being written to from a web browser, so is the browser integration necessary as well?)

I understand there's often a lot of files in installation packages, but equally, it's starting to become a real source of irritation.

 

the excessive pausing is one thing, but it's after a slow source server on 3gb file, and THEN for the download to fail at that 99% stage where it's a real kick in the jewels!

we've got a corporate licence on 250users - small compared to some businesses, but we chose nod32 specifically for it's speed, efficiency and reliability. shortly after taking out this licence pack, the problems I report become present! ah well - cie la vie!

i think i might report this issue officially to eset support and reference this thread. even is theres no fix, confirmation that it's been noted and looked into would be nice

 

For these reasons you have an option to specify limits for scanning objects/archives. One cannot expect 3 GB files to be unpacked and each file scanned within an eye blink. Even copying such a large file to another folder on a clean system without an AV will take quite much time.

You're free to set the scan limits yourself and thus set the balance between the speed and the thoroughness of archive scans.

 

Marcos - I don't think anyone expects the impossible as such; as a software engineer myself, I appreciate the technical limitations.

However, what is important is that the product should come with sensible defaults, suitable for most users. Taking minutes to scan something isn't sensible for anyone other than the totally paranoid, so why not ship the product with a default setting that avoids this? Others have pointed out that the product, as installed, scans all files rather than the most likely candidates (bizarrely, the ones you get if you then actually click the default button - but that's another story).

It's not that NOD32 can't be made to be sensible - you've helpfully pointed out the various tweaks - but it should come with it set up like that out of the box. Don't make us think!

As an aside - one of the tweaks I made was to turn off startup scan after every DB update - the third scan in a day eating a CPU core was just too much to bear. Again, a sensible default like "maximum of once per day" would go a long way to solving this.

I do hope ESET take note of people's pain points, and work to remove them in future versions. Telling them how to do so themselves after they've been hurt really doesn't leave customers feeling great.

Many thanks!

 

being in the IT field myself, it believe my reported issue is a BUG in nod32 and not the desired behaviour.
to my untrained eyes (im no software engineer!), it appears nod32 is stopping the download at 99%, scanning (... the undesired scan), then resuming the download to 100%, and THEN running another scan (...the expected scan).

ie: it's scanning the file TWICE. once at 99% and again at 100%.
however, the 'scan' at 99% breaks the larger downloads.

depending how big the file is, then when nod32 stops the download at 99%, then something times-out and the download will usually end prematurely and never reach 100%.

as i've previously stated, setting a scan filesize limit does not work.
this could well tie in with it being an undesired scan at 99%. i havent checked it, but i bet that the filesize scan limit only affects the scan at 100% where firefox download manager states "scanning for virus".


*if* this IS desired behaviour where it scans the download twice, then it's a new feature that has been introduced over the last 3months (approx). nod32 (even the earlier v4 releases) did not have this issue, and if it did, i would not be using nod32 in a business environment. our parent company uses sophos and it was a toss-up between that and nod32. nod32 won due to our IT dept having more experience and no issues with nod32 from personal licences.

thankyou for your help marcos, and i appreciate your responses. and yes, i agree with your statements. however, i believe the issues in this thread are no desired behaviour and no matter what settings/limits are imposed, the issue will still be present.

the only fix i've found is to completely disable nod32, which is not convenient or as im sure you will agree, not recommended.

 

...if it is a new feature that is meant to be present, it would be nice to know exactly what that "99% scan" feature is, so we can either tweak or disable its' setting so that we don't experience this anymore.