I have had a problem with PSKILL.EXE for awhile now.
I had originally put it in Chest, but avast! kept on making alarm bells, so then I deleted it.
But avast! keeps on indicating it finds it.
I. have run ewido anti-spyware & adaware (in safe mode & normal mode) and they do not find anything amiss.
I have also run many scans with online antivirus tools (trendmicro, symantec, RAV) and they also do not pick anything up.
I have turned system restore off, restarted, etcetera.
Nothing helps.
I understand that PSKILL.EXE can be a legitimate tool that can be used for harm, but in any case, I want avast! to stop the alarm bells. I have done everything I can and I’d rather just ignore it.
Can someone direct me on how I can put PSKILL.EXE on some sort of Ignore list?
C:\WINDOWS\RESTORE.INS\C:\OEMCUST\TOOLS\WIN32\PSKILL.EXE [L] Win32:Pskill-E [Tool] (0)
During the file delete, error occurred: There are no more files
C:\WINDOWS\system\RESTORE.INS\C:\OEMCUST\TOOLS\WIN32\PSKILL.EXE [L] Win32:Pskill-E [Tool] (0)
During the file delete, error occurred: There are no more files
I’m not sure if you need the entire path, the file name may be enough. If not use the entire path. Hope it works. Please post back if it does or does not.
The problem is what file/s to exclude, C:\WINDOWS\system\RESTORE.INS and C:\WINDOWS\RESTORE.INS are the ones to exclude as they are the files that contain pskill.exe, restore.ins being in effect an archive file.
The wildcard * will help so you don’t have to type the full path, C:*\RESTORE.INS should work for both locations.
I’m surprised avast skipped as I would have thought the path in explorer would end after restore.ins although it is possible to name a folder with a period in the folder name.
If the C:*\RESTORE.INS doesn’t work try C:*\RESTORE.INS*
I’m also concerned about the Topic title as anyone searching about detections of pskill.exe may find this and only think they should simply exclude it without doing any investigation. pskill.exe in another location could be an entirely different ball game.
(I wonder if doing so will cause me to unecessarily skip other files? I'll take a look at the report when I'm done.)
Personally I don't think you should worry about not scanning this file/folder as you have seen it is somehow protected and may also be write protected so probably of limited risk.
I’m also concerned about the Topic title as anyone searching about detections of pskill.exe may find this and only think they should simply exclude it without doing any investigation. pskill.exe in another location could be an entirely different ball game.
That’s a good point. I’ll change the topic title. I only choose to exclude it because other scans say the system is clean.
I’ll write again when I see how the next avast! scan goes.
ok… so I added both:
C:*\RESTORE.INS
C:*\RESTORE.INS*
to the Exclusions folder.
But tonight I did a Thorough scan, the alarm bells went off once again for PSKILL.EXE and the report said this:
C:\System Volume Information_restore{1E99F574-4FED-4B1A-B925-343BD1F85271}\RP12\A0006342.INS\C:\OEMCUST\TOOLS\WIN32\PSKILL.EXE [L] Win32:Pskill-E [Tool] (0)
During the file delete, error occurred: There are no more files
At some point when you moved, deleted or whatever action you took to deal with the pskill.exe file which is in a sub folder of windows, system restore created a restore point back-up and that is what avast is detecting.
The c:\System Volume Information folder is a part of the system restore function and as such is protected by windows, the only way to clean infected _restore points is to disable system restore and reboot. This will clear ALL _restore points. Once you have disabled system restore, reboot, scan your PC again and if clear enable system restore.
Win XP-ME - How to disable System Restore
Your exclusions have not effected avasts detection, your original actions in dealing with a suspect file in a system restore protected folder has created a copy somewhere else and it is that which is being detected and that would still happen even if you hadn’t created the exclusions.
ok, so this time, I turned off system restore, restarted immediately, did a Thorough scan–no alarm bells. yay!
I turned system restore back on. I did another Thorough scan, and once again:
C:\System Volume Information_restore{1E99F574-4FED-4B1A-B925-343BD1F85271}\RP2\A0000114.INS\C:\OEMCUST\TOOLS\WIN32\PSKILL.EXE [L] Win32:Pskill-E [Tool] (0) During the file delete, error occurred: There are no more files :o
Bah!
Thank you everyone for your advice. I guess I’ll have to live with it.
There might be a little confusion here… oldman’s post suggested putting the path into the list of Standard Shield exclusions.
While this is a reasonable suggestion, it affects Standard Shield (i.e. the resident protection) only - not on-demand scans from Simple or Enhanced User Interface. To exclude the file from such scanning, you must put the path into the other exclusion list (in Program Settings / Exclusions).
Also I’d like to ask: what is this RESTORE.INS file? Where does it come from (i.e. what application does it belong to)? Or is it a folder actually?
(sorry for my ignorance if it’s something obvious)
I’m afraid that to be able to tell more about the problem with the actions, I would have to see the RESTORE.INS file. Maybe there is a problem with this particular format, but I’m not able to say without checking the file directly.
(On the other hand, if this file is some kind of OEM system-recovery container, it might not be the best idea to modify it, e.g. by removing files from there.)
That is basically what was said in the other topic so you have to exclude it from the scans. It would also appear that in some cases it is somehow protected so you can’t delete it or move it or the contents within, not that you would want to.
Restore.ins is also a very big file, I think over 1GB was mentioned in the other topic, so not something easily sent for analysis, perhaps someone could post it to you like I did for the big memory dump.
The trick is deciding if the pskill.exe is a tool within an OEM system recovery container by its location within restore.ins and the path listed above.