On a now regular basis Avast Free is bloating our Win7 System SSD which causes severe problems.
The remaining free space is filled until the last byte, which sometimes even does not let use our pc anymore, because its unable to even write little log files.
This is a real issue and needs to be fixed asap.
On our 120 GB - system SSD we could allocate using WinDirStat under path USERNAME\AppData\Local\Temp_avast_ a file with the size of 29,1 GB.
After deleting it (too big to save a copy on HDD, says Windows) the same file seems to be written some time later again (we could not track the frequency).
Please look into this issue and provide a fix or a note here how we can avoid this unacceptable behavior of the software - or if we have to deinstall Avast to find another solution.
We can’t tell now, I started this as suggested but change can only be seen if that bloating does not start again, as I said this is not happening instantly but by some strange schedule.
And if you carefully read a google search on that issue you will find that this is not only us having that problem.
I don’t feel like this fixes the issue. We will see…
This is certainly not a normal behavior (and I don’t think it has actually anything to do with SSD).
How quickly gets the file re-created after you remove it? (matter of hours, days, weeks?)
Would you be able to use Process Monitor to track the creation of that file and send us the log once the file is created? (Now using just the mask *_avast_*.tmp will get a lot of hits, but after the huge one is created, we can filter them out using the exact file name.) The temp file may be related to some scan - and even though the log wouldn’t tell us what exactly got scanned, the stack could at least indicate whether it was something local, or some web traffic, or something else.
Thanks.
Thank you igor for looking into this and taking this issue serious.
I would be happy if I can help to solve it somehow.
I have to guess, there could be two possible answers:
-ONE - It -could- be adjacent to a scheduled system backup that Win7 has implemented since the setup of this machine in 2012, and appeared to happen first after we updated to the prior version of Avast that is now actual.
-TWO- From my gut-feeling this has to do with the local or smartscan cache of your software - pretty sure it is not webtraffic.
It seems as if the backup would be scanned and put into the Temp/avast folder, if that makes sense to you?
As of now the folder remained empty after deletion yesterday, like 12 hours back from now as I write to you.
Those temp files can be used for different things… it’s really hard to say where they may come from. The most common use (at least from my point of view) is unpacking archives when scanning. I can imagine there’s some special file somewhere on your disk that is detected as an archive, possibly in an unsupported format, and when Avast tries to unpack it, this happens. But I’m not saying I find it very likely, especially if you say it seems to be bound to a specific version of Avast (while the unpacking engine, being part of virus definitions, is shared across versions).
Maybe there isn’t any real data written to that file, maybe it’s just “making the file incredibly large” by mistake… and in that case it could even be related to Web Shield (i.e. there wouldn’t have to be any communication of this size).
So if Process Monitor logged the moment the file was created (or rather when it was made that huge)… hopefully the stack would tell us more.
There’s one thing that I find a bit strange… and that’s the fact that you were able to remove the file. I mean, even if the file were this huge somewhere during some operation, it should have been removed afterwards - and if the operation (whatever that is) is still in progress and the file is still in use, you shouldn’t be able to remove it (unless you e.g. restarted the computer to delete it). Can you please check if you don’t have other (recent) files called unpXXXXXXXX.mdmp in C:\ProgramData\Avast Software\Avast\log folder? Such files would be dump files corresponding to the crashes of the program…
Thanks.
All files in that folder end with .log, no unpxxxxxx.mdmp
To delete the file I just followed the path shown on WinDirStat in Explorer.
As I tried to make a copy to an external HDD just in case windows prompted something like “file too big to copy” so I left the idea, went back to the file, marked it and pressed delete.
Windows prompted “Too big for recycle bin, will be deleted permanently” which I then accepted.
Short check on discspace in Explorer said back in business, 29,1 GB free again.
No other errors shown, no fancy workaround or restart of computer needed.
Since I will have some days off I decided to pause Windows Backup Schedule if that is part of the problem, so maybe we can not replicate this issue within the next weeks, but if so I’d be glad to come back to this thread and continue help resolving and preventing this strange thing to happen again.
What you could try meanwhile is to search on google, it seems that some more got this issue, it is most likely on SSD, but I suppose that not SSD is the issue, but having those setups you just notice it quicker since they are most probably still smaller sized than regular modern HDD setups.