Avast! Stops scanning or doesn't start

[Nukem]

I suspect both problems are connected.
Since the scan stops around the end of the first HDD.

OS: Win XP with SP3
Avast! 4.8.1296
VPS: 081227-0
new E8400 - Gigabyte EP45-UD3R - 4GB Ram (restricted to 3GB by the BIOS)
HDD0: 250GB Samsung HD252HJ (~19,5GB used)
HDD1: 1TB Samsung HD103UJ (~12,2GB used)
both HDDs are 1 Partition each over the whole disc with a 5GB hidden image partition from the OS on the first HDD
"Thorough Scan with Archive files" or "Standard scan without archive files"

After about 10 min the scan doesn't advance, the actual file displayed is a random from the c:\Windows\WinSxS\x86_Microsoft.Windows...
Half an hour later i get bored (also left it over night, no change) and hit the stop button, sometimes it takes 10sec sometimes the stop reacts immediately.
No freezes elsewhere in the system.
When i select only the C-Drive in the explorer and let that scan it runs through without findings.
But when i select the second HDD then i keep on waiting for the scanner to initialize.
The same happens when i only select a folder on the second HDD and try to scan it.

Is it possible that the scanner can't handle the 1TB drive?

[Lisandro]

Is it possible that the scanner can't handle the 1TB drive?

I don't think so.
You can go to the program settings and turn on the creation of the report file (with "OK files" to be included as well in the report). This way, you can find out where the scan really stopped (it's going to be close to the end of the report).

After avast! disappears, check the end of the report file - the "troublesome" file is likely to be close to the end (close in the sense that this particular file will probably not be written in the report, but the previous one will be the last line, so it shouldn't be hard to guess). We would certainly like to have this file - if it really causes problems to avast! - so that we could fix the problem.

The report file created (if you turned it on in program settings) will be (default location) at <avast4>\Data\Report\Simple User Interface.txt

[Nukem]

Found the bugger, a 12.1GB big .7z File.
That's the first file in D:\ and only 2 more small .zip.
He is trying to scan that file and goes nuts.
If i try to single target the small ones it works, but not the big file.

Aw well, deleting it and starting a new run.

UPDATE:
Scan running smooth now.

Thanks for the help and sorry to have bothered you.

[DavidR]

Well if it is 12.1GB in .7z format it would be absolutely huge if avast was able to unpack it to scan it.

Normally very large archive files are reported as Unable to Scan (at the end of the scan), potential decompression bombs so I don't know if support for the 7z format might have been the problem. I'm going to create a large 7z file and see what happens on my system.

[DavidR]

Update:
Well I created on of a little under .5GB and used the ashQuick.exe to scan it, it took a little while initialising before the scan, but the total time for the file was a little over a minute (but I have a relatively quick system) and a total of 1.4GB of files were scanned.

A lot of that could potentially have been done in memory but a 12.1GB file no way.

[Lisandro]

He is trying to scan that file and goes nuts.

How much free space do you have in drive C: and D:?
Generally, it is processed slowly (as avast needs to unpack the file) but it shouldn't crash.
Also, I think it's too big to be a decompression bomb.

[DavidR]

Based on my trial, a 7z standard compression could unpack to 3 times the zipped size so I would say that would be considered as one.

If they are going to apply an arbitrary size over which it isn't considered I don't think they should bother with the decompression bomb check at all. Perhaps they should have an option not to scan files over that arbitrary size, in the same way SAS allows you to exclude files over 4MB in size from scans.

[Nukem]

Well the free space could not have been it (170GB on C:\  and 920GB on D:\ ).
The compression wasn't that high since unpacked its 12.3 GB (World of Warcraft patched to v3.0.3 since repatching is a pain in case anything goes wrong).
Maybe the file itself was corrupted.
Since i already deleted the file, i can try to repack it again and test.

There was no crash of the scanner, but it simply didn't advance with the scan process.
The stop / cancel buttons worked. Everything else ran fine.

[DavidR]

Personally I wouldn't pack it again just to sit waiting to see if it would happen again.

But if I did, then I would probably save it in a different archive format, e.g. .zip and see if that was scanned successfully. If it was then you would be confirming a problem in 7z, either compressing large archive files or avast uncompressing large 7z archives.

[alanrf]

I finally decided - in my weekly scan - to stop allowing avast to scan my .7z linux iso files folder because even for individual 2+Gb files avast was taking (what seemed like) an eternity to scan them.

[DavidR]

I too exclude my HDD backup image (Drive Image 7.1) from on-demand scans as they when compressed are still in the region of 2GB.

[Nukem]

I packed it again as .zip Archive and it takes 4 min for the quick scanner now.
Seems like the old .7z archive was corrupted or the scanner didn't like it.

Thanks for the tips and help.

[DavidR]

No problem, glad we could help.