full system scan freezing when storing persistent cache is checked

[molunbun]

Hi all,

I'm using avast internet security 6.0.1203. I tried to perform a full system scan with "store data about scanned files in the persistent cache" enabled(which is the default setting) but the scan won't proceed beyond 14%. If that option is disabled, the scan runs fine.

OS is Windows 7 SP1 x86
I'm looking forward to seeing a solution to the problem. Thanks for the help.

[igor]

Do you see any hard disk activity - after the scan stops progressing? Is any process using any significant amount of CPU at that moment?

Would you be able to create and upload the a dump of avast! service process taken when the scan freezes? Here is how to do that:
1. Disable avast! self-defense (avast! settings / Troubleshooting and uncheck the option "Enable avast! self-defense module")
2. Run the scan and wait for it to freeze
3. Start Windows Task Manager, make sure the option "Show processes from all users" is checked. Select AvastSvc.exe process, rightclick and choose "Create dump file".
4. Wait for the dump generation to complete, go to the folder shown in the window that appears, and upload the file AvastSvc.dmp to ftp://ftp.avast.com/incoming

[molunbun]

Do you see any hard disk activity - after the scan stops progressing? Is any process using any significant amount of CPU at that moment?

Would you be able to create and upload the a dump of avast! service process taken when the scan freezes? Here is how to do that:
1. Disable avast! self-defense (avast! settings / Troubleshooting and uncheck the option "Enable avast! self-defense module")
2. Run the scan and wait for it to freeze
3. Start Windows Task Manager, make sure the option "Show processes from all users" is checked. Select AvastSvc.exe process, rightclick and choose "Create dump file".
4. Wait for the dump generation to complete, go to the folder shown in the window that appears, and upload the file AvastSvc.dmp to ftp://ftp.avast.com/incoming

I saw no disk activity and no process had high cpu usage when the scan stopped.
The dump file has been uploaded as AvastSvc.7z.
Thanks for the help.

[igor]

Thanks for the dump. You are right, the scan is frozen, waiting for an operation to finish - but this operation is not being performed anymore.
Unfortunately, I can't say why this is happening - because whatever has caused the problem, had happened in the past (when scanning some previous files) - and it's "gone" at the moment the freeze occurred.

I kinda doubt I will be able to reproduce the behavior, but just in case - could you please upload two more files from your disk (that are connected to the situation)? Namely:
C:\Program Files\ASUS Xonar DS Audio\driver\XonarDS.INF
C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem29.CAT

Thanks!

[molunbun]

Thanks for the dump. You are right, the scan is frozen, waiting for an operation to finish - but this operation is not being performed anymore.
Unfortunately, I can't say why this is happening - because whatever has caused the problem, had happened in the past (when scanning some previous files) - and it's "gone" at the moment the freeze occurred.

I kinda doubt I will be able to reproduce the behavior, but just in case - could you please upload two more files from your disk (that are connected to the situation)? Namely:
C:\Program Files\ASUS Xonar DS Audio\driver\XonarDS.INF
C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem29.CAT

Thanks!

Uploaded as oem29;XonarDS.7z
Thanks

[igor]

Great, thanks a lot.
I was able to reproduce a crash inside of the signature verification code - so I should be able to fix the problem in one of the following virus definition updates (fixing the internal crash avoids the condition that led to the freeze).

[molunbun]

the scan now freezes at 66% when scanning some files in C:\Windows\System32\DriverStore\FileRepository

[igor]

The fix hasn't been released yet
Actually, every time the freeze occurs, you move "one file forward" (one file more is scanned) - so now you probably ran out of the troublesome files in the original folder and moved a bit further.
Anyway, the fix will be present in the first today's definitions update.