avagent cpu bound

I initiated an on demand scan of all local drives for two machines from adnm. It ran fro almost an hour and a half for 1 10 GB drive and 1 20 GB drive. I figured that was way to long so I went to the local machines and brought up the task manager. avagent was running at a 99% cpu level.

Well the scheduled scan runs inside AvAgent.exe so that’s not much of a surprise, is it?

I wasn’t clear enough, avagent is still running at 99%, there is no disk activity, and the adnm believes the event is still processing. However it isn’t scanning anything. I think I hit an infinite loop in avagent somewhere.

Hmm, that’s not very likely (except for a really bad file encountered during the scan)… but anyway, you’re saying the scan hasn’t completed yet?

The same thing occured on both of the machines??

Correct according to adnm it is still processing however the speed is 0.0, the file count is not increasing, nor is the data size. I have even gone in and set the show detailed info option on the client and nothing appears nor is the blue ball spinning. Yet the avagent is still maxing out the cpu.

And that is on both machines. One a W2K server and one is W2K pro.

Has it found any viruses during the scan?

It hasn’t reported any on either machine.

Was the scanning task set to scan inside archives?

Actually, I may know the cause: this version of managed avast features some new unpackers that may not be perfectly stable yet.

Try running the scan with archive scanning disabled.

By the way, it would be quite useful to turn on generation of the Report file for the scan (even for OK files) to get an idea about where it actually stoped…

See the scanning task’s properties for details.

Also, you may try to run an interactive scan locally from a local scanner app (simple, enhanced, aswCmd.exe etc…). It would be interesting to know whether the hang will occur even in this scenario.

Thanks.

Yes I had checked all packers (like to be thorough you know). I have since unchecked all and the scan ran in 20 minutes. I am now running a scan logging all files with all checkers picked. I’ll report back later.

Cool thanks. In the meantime, I’ve noticed (and fixed at the same time) that the console was not showing scanning speed correctly…

Again, big thanks for your help.

The rerun with all scanners checked gave the same results. Avagent cpu bound, no scanning the task running forever. On one system the last file logged was a .htm file - should not have required a scan check there. The other machine’s last file was a cab file. So what packer scanners are stable at this point? I think like only 1 or 2 are on by default. I imagine work is under way to fix the others?

This also reminds me of another feature request. Is it possible to make the text displayed in the adnm console copyable? For instance I selected the text of the filename to paste into this posting and was unable to do so. Cntrl C doesn’t work nor is it an option on a right click.
Or when you’re in the computer catalog looking at the detailed info on a machine you can’t select any of the info to copying.

Most of the packers should be stable. Except for the new ones - CHM, RPM, CPIO, 7ZIP and a couple of other (not CAB though).

The tricky part is that in case of freeze, you won’t actually see the offending file in the log, just the one before it. In other words, files are logged after they’re scanned, not vice versa…

Have you tried running a scan locally? It should be much easier to work with in this case. aswCmd.exe would be my tip.

Run aswCmd.exe /t=A /a /c

to get optimal results.

About the feature request: that sounds good but I’m not sure if it will be possible to implement it to the lower-right pane (the properties window)…

Thanks
Vlk

I’ll give the local scan a run and report back. As for text selection/copying another instance where it would be useful is in the avast log viewer. That way we can cut and paste any errors easily to send along.

It’s definitely the packers. Running the command line scan sent aswcmd into 100% compute mode and has been running for 5 days on a 10GB drive half full. I ran a full scan of all the machines remotely this weekend with minimal packers checked and no problems.

Could you identify the problematic archive, which should be close to (or rather shortly after, as Vlk explained) the end of the report file when full logging (i.e. including the “OK files”) is specified?

How would I determine what file avast is currently scanning? Does it scan in alphabetical order or some other order? My understanding is that files that are logged are the ones avast is finished with. So I could look at the next file after the one that is scanned? Would turning details on in standard shield do it?

Do you think you could isolate the file that’s causing the problems?
It should be pretty easy with a local aswCmd.exe scan (the name of the problematic file should be displayed on the screen at the moment of the hang).

BTW it might be the CHM unpacker. I’ve heard that it may contain some problems (at least in the version you’re using).

BTW2 I know updating from RC2 to RC2a does not work for the AMS/console. But what about the clients? If it doesn’t work, can you post the corresponding setup.log file?

Thanks
Vlk

Well, I think avast! doesn’t do any sorting of the files to be scanned - but as far as I know, the API functions enumerating the files return them in alphabetical order on NT-platform. So, I think you can expect them to be in alphabetical order (at least you can check by the previous ones).
You are right that if avast! freezes on a file, it wouldn’t get logged; however, you can judge by the previous one (if the problem occurs after the first file of the archive, even the previous archive files should be there).

The easiest way to find out is to turn on the creation of the report files for the particular task (and set the “OK files” to be included there as well). Or, try to use aswCmd with the corresponding command-line.

OK, Vlk was faster ;)… and checking the aswCmd window would probably be the easiest.

I tried one client update it worked fine.

I’ll rerun the command line scan. I don’t remember the name of the file but it was a .dll . I’ll see what it comes up with this time.