Net Client eating cpu

started 12/18/2006, still a problem 2/11/2007

I am trying to rollout a new set of desktops. The image is win2k pro,
all current patches, plus MS Office 2003 Enterprise Edition (+
Business Contact Manager - inc sql server). We have ADNM with all
clients being NetClient Avast 4.7.599. Images are built direct from cd
behind firewall with no neighbors. Avast client install package from
1/2006 (built in local ADNM, carried on cd) then updated through firewall.
MS update run repeatedly until no patches remain to install.

I built the image off-network and it worked fine there. When I
connected it in the company network this first PC saturated the proc
as soon as I updated to current Avast Client (and rebooted). Task
manager shows aswserv.exe as the culprit 100% cpu (running at highest
priority class). System is Dell gx260 1.8ghz p4, 512mb mem, 20gb disk
(4.5gb in use). Disk active LED shows clusters of heavy activity
(which allow some probing around by causing i/o wait). No entries
seen in Antivirus log, system log, or security log.

I thought this might be an initial scan, but it failed to complete
after 1:30:00 cpu time. Unaffected siblings running w2k pro and
Open Office scan in 30-45 minutes.

Other computers of same model do not evoke this problem - but do not
have Office 2003 either. I have removed the initial offending computer
from service and kept the config unchanged so I can test it.

Isolation tests determined the looping occurs when MS update is running.
Disabling Standard Shield allows update to complete normally. Re-enabling
Standard shield returns the problem. Problem is same for auto-update
check or manual check. Shield shows hundreds of scans of \winnt\installer
*.msi and *.msp files. Only about 20+ files are accessed, but are
scanned repeatedly.

I updated to 4.7.652 client and still have the problem - but it is
less intense!?! Still very heavy cpu usage, program usage not possible,
at least the mouse tracks better now. Number of file scans increases more
slowly now. Problem pc now replicates its misbehavior behind my firewall
isolated from all other PCs on the build network. No errant firewall
traffic is in the logs.

Pc config available in html form if requested (all patches w/version,
all installed products w/version, detail enough to sleep by).

Our normal desktops using XP Pro and MS Office 2k do not have any
problem. Another image with MS Office 2003 Standard Edition and win 2k
pro has same problem.

I know MS is not my friend, but this seems a little extreme…

This sounds like someone has enabled unpacking of all files for the Standard Shield provider. This is definitely not a recommended thing – for example, the \windows\installer*.msp files contain thousands of objects, and having these scanned (i.e. unpacked and scanned) on-access is not a good idea.

Can you please check the Standard Shield’s settings (in the ADNM console)?
I’d recommend using only the default archives, i.e. DOS self-extracting packers, Win32 self-extracting packers, and NTFS Alternate Data Streams.

Thanks
Vlk

Ok, that sounds like you’ve guessed it pretty well. I set up scans to check more than default out of paranoia… I’ll try it and report back.

If this is it how can I have different settings for serious hard-core scans versus the on-line stuff? Will that just follow from the fix of setting for Standard shield only? (I don’t recall that as an option is why I ask).

There’s a big difference between ON-DEMAND and ON-ACCESS scanning. On-demand is what you run e.g. scheduled, it usually scans the whole drive and there’s no problem making it as thorough as possible. On-access, on the other hand, is what’s done whenever a user (or process on the user’s behalf) accesses a file - and is therefore quite performance sensitive.

Standard Shield is the main provider of the avast on-access scanner.

Telling it to unpack all archives will certainly slow things down, and is not recommended.

Thanks
Vlk

Ok, I’ve run test now that I reset the policy via ADNM. Once I have the client request an update of the engine the performance problem settles down. My initial images still have the issue until an update, so I’m guessing the policy is embedded/inherited there when it was built.

Thanks for the fix!