Essexboy noted: I must admit as soon as I saw the number of posts on this I did an immediate full scan on my system to check if it was a FP. I received no hits on those files … Win7 64 bit
This post is not exactly “new.” It was provoked by the three instances of the Win32:Cycbot-KI[trj] “warning” that appeared 3 days ago (I’m using Windows 7, 64 bit.). Actually there were only two instances as the third flagged file was a duplicate of the first, apparently being a systems file that should never have been removed!).
When given a “Threat Alert” after or during an Avast! scan, how does one who is not particularly savvy with computers differentiate between a genuine virus (which needs attending to and should probably be removed, repaired, or moved to the virus chest) and a false positive which probably should be left alone?
I asked this question before at the end of my post but it probably got lost in all the verbiage. Sorry.
I got the same problem, but with Windows XP… I am really stuck and have no clue on what to do because the way that works for windows 7 does not work for me.
But - and please forgive my lack of knowledge - how can one tell whether or not the flagged file is a system file? Is the presence of “Sys” in the file name sufficient evidence or is the “.dll” also necessary also (or some other component)? Had I known the answer to this question, I would not have moved the false-positive file under discussion, c:\windows\syswow64\kernel32.dll>[emul], into the Chest.
Essexboy is on holiday now as his last post indicates.
In certain locations the kernel32.dll is a system file, this is also an important system file. The problem being this file is a bit weird as it is a 32bit dll that is why it is nit the syswow64 folder so that 32bit applications can use it.
When executing 32-bit applications, WoW64 transparently redirects 32-bit DLLs to %SystemRoot%\SysWOW64, which contains 32-bit libraries and executables. ...
For some reason the emulation function in the scan considered this infected, I don’t know what this reason is.
A bit of speculation on my part after information from another source - In this case if you had ignored the detection and rebooted, then the copy of the file in the syswow64 folder would have been recreated and may not be subsequently detected. So the detections on files in the syswow64 folder are a bit weird as they aren’t actually the original file but a copy of it. So I don’t know why the emulation element found it strange enough to flag it.
But I don’t know what would happen with the other occurrences, which is why following that guide was advised by essexboy.
