bryan said:
What files, i.e. do you mean particular data files, or those programs?
Do you mean "IExplore.exe has ... and will be shut down" dialog boxes?
Or BSoD STOP error screens?
Or do you mean Windows shuts down?
OK, that's always a good test. If starting the program, then going
File, Open and opening the data file that way, is OK - but "opening"
the file in Windows Explorer is not, then you have a file association
problem. Malware is a player in this space, in that patching into
commonly-used file associations is a great way to assert malware
activity without using the more obvious startup axis that is
suppressed in Safe Mode and manageable via MSConfig.
What's more interesting here is the LOCALS~1\Temp part, i.e. your user
account's Temp directory. That's an odd place to put code that you
ever want to see again, and it's odd to integrate code in such a,
well, temporary location (any number of things can clear Temp, and
thus break the integration). Smells like m-a-l-w-a-r-e to me :-(
Even "argh that's too difficult" advice?
OK, the "easy" advice is to trust Safe Mode to suppress the malware,
and run your antivirus from there. When that works (which is a lot of
the time) it will be because the malware simply isn't trying that hard
to retain control of your PC.
But we already suspect the malware's smart enough to patch into the
file associations, and thus is likely to be active in Safe Mode too -
potentially including Safe Mode Cmd Only (if you were to "start" a
file that's associated with the malware).
And that's before you consider other integration methods that may be
less buggy, and thus haven't drawn attention to themselves.
http://cquirke.mvps.org/whatmos.htm covers your maintenance OS
options, i.e. how to tackle malware that "owns" your system without
letting it run first. As the malware could be anywhere within the
infected HD and the chain of code that starts from boot, you'd want to
run NO code off that system at all, when scanning it.
Since I wrote that article, Bart PE has come to the foreground as THE
premier maintenance OS for XP.
MS offers zero for you in this regard, and their own WinPE is so
tightly licensed that hardly anyone uses it (or dares admit doing so -
which stifles public collaboration, development, forum support etc.)
Linux isn't safe to write to NTFS, plus it's hard work to learn
another large and complex OS just so that you can maintain some other
OS that can't wipe its own butt.
DOS mode is still useful, but only if you avoid NTFS and your HD stays
on the happy side of the 137G barrier.
The other option is to drop your HD into a clean PC and scan it from
there - that gives you full access to everything that runs in XP.
Trouble is, it's not enough to simply not boot infected code - you
also have to avoid running infected code as a side-effect of handling
"safe" material that is malformed to exploit itself into raw code
action. XP's not very smart on this, to put it mildly, and unlike a
Bart PE CDR, the host system is not read-only, and thus could be
infected by the drive you are trying to scan.
Links:
http://www.nu2.nu/pebuilder/
Forum support:
http://www.911cd.net/forums//index.php?s=2d8129076720e6e30cc2031100d2b258&showforum=30
<shrug> It's neck-deep in the infected OS. If it found a problem,
whether it fixed it or not, or if it died trying, that would tell you
something. If it says it can't find anything, that tells you less.
You're still working within the infected OS, that's what undermines
any certainty there.
In addition to chasing malware, I'd:
- check the hardware (RAM, HD); DoA components happen
- check AutoChk/ChkDsk logs to see what was "fixed" (=corrupted)
- check av logs to see what was "cleaned" (may be corrupted too)
- review installations, looking for "DLL Hell" effects
But that code integration pointing to Temp really does focus the mind
on malware, and that looks the most likely factor.
-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
