Any of these ring a bell to anyone?

  • Thread starter Thread starter Menno Hershberger
  • Start date Start date
M

Menno Hershberger

iau.exe
stisvsq.exe
msqdevl.exe
mservice.exe
svshost.exe (not svchost)

All of these are running in task manager on a customer's machine. If I
end task on them, they don't regenerate (till next logon). All five of
them are entries in msconfig TWICE. I can clear the checkmarks on all of
them, OK it, and then choose NOT to restart, then go back to msconfig and
they are all checked again. Just as they are if I DO restart.
AdAware is the only antispy app that finds anything and that is
CoolWebSearch. And I can run it twice in a row and it finds it every time
(either 2 or 3 instances). And yes, I've done all this in Safe Mode with
System Restore turned off, all temp files cleaned out (everywhere).
HiJack This is only showing items I KNOW are OK.
This may or may not be related... there are four users. In just one of
the user accounts, AdAware takes forever to come up, as does anything
else. It even takes Task Manager ages to come up. But when it does, it's
saying
97-99 System Idle Process (even when AdAware is still trying to load).
Graphics are slow. Windows go away slowly starting at the top down.
Sometimes a closed window leaves a blank spot in its place. This is just
in this one user account. Task Manager shows pretty much the same things
running as are in the other accounts.
And when AdAware finally does come up, it seems to do its scan just as
fast as it does in any other account.
Everything else seems to run fine in all accounts but just that one. In
that one, it's just slow loading and graphics. Same screen resolution as
all the rest.
MSAS doesn't find anything in any of the accounts.
Anything here look familiar to anyone?
 
OK, between that link and another one it led to, I was able to get rid of
them. Symantec called it "Adware.EasySearch". There were instructions for
manual removal and they worked great. That got me down to the CoolWebSearch
that AdAware kept finding over and over. I tracked that to three registry
keys that AdAware couldn't delete. I couldn't delete them manually
either... until I set the permissions on the keys. Then I got rid of them.
I have run Adaware, SpyBot S&D, and MSAS on all four accounts now and
everything is clean. The one user account is still slower than hell, but
I'll take that problem to another group. If nothing else, I'll backup all
that users documents and delete the account. And recreate it.
Thanks for the help!
 
I doubt this is relevant, but have you tried a rootkit tool? F-secure's
fsbl.exe or sysinternals rootkitrevealer?
 
No, but I finally DID find out the problem. Remember when I posted the link
to that AdAware screen shot with 10,674 critical objects? Well, this
account was the one I had run it in. I found a HUGE quarantine file in
Documents and Settings\user\Application Data\Lavasoft. I deleted all the
quarantine files and now AdAware comes right up... as does everything else
I run afterwards. AdAware was always the first thing I ran in that account.
Whatever it was doing to bog it down carried on into whatever you did
afterwards.
And it only took me two days and two nights to figure it out!
 
Wow--so Microsoft Antispyware isn't the only app which runs into trouble
when the number of files in Quarantine gets too high!

(Although, by reports, if that had been Microsoft Antispyware--you'd have
been waiting hours, rather than minutes. I still need to try to replicate a
very large MP3 collection in quarantine.
 
I didn't get the whole path in that post... it was Documents and Settings
\user\Application Data\Lavasoft\AdAware\Quarantine
(striving for perfection)
 
There are stranger things.....
For Quarantine, I think it is just getting it ready to display in the
window. I've almost never had anything in quarantine, but I believe that
screen shows all the items in quarantine, and I suspect they are toted up on
the fly before display.

When you go to do a scan, there's a similar process to estimated the scan
time--and that estimate is displayed--so we had reports here of long lags at
that screen when a previous scan involved lots of lines--the program had to
read all that in and tote up or compare the starting and ending times, and
apparently the code was none too efficient.
 
Back
Top