sig.tmp files in C:/WINDOWS/Temp folder - what is that?

[Asyn]

EDIT: it seems that sigN.tmp files are created 8 minutes after system boot (or perhaps after Avast! is started).

Hmm... avast runs a rootkit scan 8 minutes after start.

[Tetsuo]

Hmm... avast runs a rootkit scan 8 minutes after start.

Asyn, could you please check when those files are created on your system? e.g. 8 minutes after system boot etc.

[Asyn]

Hmm... avast runs a rootkit scan 8 minutes after start.

Asyn, could you please check when those files are created on your system? e.g. 8 minutes after system boot etc.

I'm away in a few minutes, but will check it later today.

[Tetsuo]

I'm away in a few minutes, but will check it later today.

Thank you, Asyn.

Anyway, I was wondering if this thread shouldn't be moved in the avast! Free/Pro/Suite section  (http://forum.avast.com/index.php?board=2.0section) so maybe it could be more easily noticed by devs...

[DavidR]

If this is happening about 8 minutes after boot, then given that it appears to be related to avastSvc.exe (FlyingRobot's image), then this could be the anti-rootkit scan (presumably controlled by the avastSvc.exe), which happens at about that time.

I found the sig*.tmp files yesterday after this topic and deleted all of them. This morning after seeing the additional posts I checked and I have a number of them again, and it would appear they were created about 8 minutes after boot (see image). The WGAErrLog.txt file date modified time would be around boot time, so the first sig7.tmp file creation was 8 minutes after that.

So I'm going to test for that and disable the anti-rootkit scan and check after a reboot if they are created.

[DavidR]

OK, test complete, this is related to the avast anti-rootkit scan.

Deleted old sig*.tmp files, stopped the anti-rootkit scan on system startup, image1. Rebooted and boot started at roughly 12:50 to 12:51, WGAErrLog.txt Date modified time is now 22/10/11 12:50. So I wait well over 8 minutes 13 in fact and check the c:\windows\temp folder and no new sig*.tmp files, image2.

So something has changed or broken in the anti-rootkit scan. Why this anti-rootkit scan function doesn't send the files to the avast temp folder c:\windows\temp\_avast_ folder; or if sending to a different folder why it doesn't clean up after it has completed the scan as the other avast scans do I don't know.

Since as has been reported this appears to have started on or about the 18th October 2011, what changed or broke in the anti-rootkit scan at that time.

What to do: I wouldn't disable the anti-rootkit scan too valuable a resource. I would recommend you do as I do as part of my regular weekly system maintenance and that is to run CCleaner to clean temp files. This tool isn't too aggressive so it shouldn't dispose of temp files that may be in use.

[Tetsuo]

DavidR, do you know a quick way to let the devs know about this issue?

[DavidR]

Not really, I'm just an avast user like yourself, but I will try.

[alpha1]

Not really, I'm just an avast user like yourself, but I will try.

dont be so modest dave. 

[Asyn]

I'm away in a few minutes, but will check it later today.

Thank you, Asyn.

Ok, I confirm the 8 minute delay and therefore the relation to the rootkit scan.

What to do: I wouldn't disable the anti-rootkit scan too valuable a resource.

Agree with you Dave.

This seems to be a newly introduced bug, but a VPS update should be able to fix this.
I'm still interested how afd.sys is related to a rootkit scan...!!??

[DavidR]

<snip>
I'm still interested how afd.sys is related to a rootkit scan...!!??

I'm not convinced that it is connected, just that it happened to be in the temp folder when you did your checking. If it were connected to the rootkit scan, then I guess after I clered the temp folder and the next day after boot there were some sig*.tmp files there but no afd.sys file as in the image in Reply #34 above and I can't recall having seen that file in temp (not that I go looking in temp often).

[Asyn]

I'm not convinced that it is connected, just that it happened to be in the temp folder when you did your checking. If it were connected to the rootkit scan, then I guess after I clered the temp folder and the next day after boot there were some sig*.tmp files there but no afd.sys file as in the image in Reply #34 above and I can't recall having seen that file in temp (not that I go looking in temp often).

Seems I wasn't clear enough.
Ok, I try again...
There are several empty files and one file with the size of 136Kb for each day/reboot.
The 136Kb file is a copy of afd.sys (See Reply #27 & #29)
It's not named afd.sys though.
Hope you understand what I mean now.

[DavidR]

Well that could have been the analysis of that file by the anti-rootkit scan as in the First post example of the contents of one of the files viewed in a text editor.

[Asyn]

Well that could have been the analysis of that file by the anti-rootkit scan as in the First post example of the contents of one of the files viewed in a text editor.

No, it's not an analysis of the file, it's a copy of the file (afd.sys) itself.
But with a name like sig*.tmp

[DavidR]

But that doesn't change the overall context of my answer, it is being analysed and that may require making a copy to work with. So it is still the same association, it is being scanned by the anti-rootkit scan not used by it as such.