Hi,
I have WinDefend B2 as well as Webroot SpySweeper (4.5.9 build 709)
installed on my XP Pro SP2 box. SpySweeper has a feature where it takes over
the
C:\WINDOWS\system32\drivers\etc\hosts file and uses it to block nasty sites
with regular updates.

The issue is that WinDefend detects SS's (apparent) access to the hosts file
and puts up an alert. I say 'apparent' because the WinDefend messages do not
identify the process or application involved. I will do more testing to be
absolutely sure that if I turn off SS's use of the hosts file, the messages
in WinDefend will go away, but the certainly began immediatly upon
installation of SpySweper.

I would like to ask the WinDefend folks if they have the means to detect
Spysweeper's processes and identify them to avoid the appearance of this
issue. One might ask why the need to run multiple programs for the same
purpose but I'm sure that's one we could debate all evening. It just
doesn't seem that one program does it all, yet.

Rob

The problem is that Spysweeper reloads the hosts file at each restart and WD
rightly alerts to a 'change' in the hosts file. If you use a different hosts
file that is fixed, until you update it manually, there is no problem. I use
mvps.org hosts file
http://www.mvps.org/winhelp2002/hosts.htm
They issue regular updates.

"RobCoh" wrote:

> Hi,
> I have WinDefend B2 as well as Webroot SpySweeper (4.5.9 build 709)
> installed on my XP Pro SP2 box. SpySweeper has a feature where it takes over
> the
> C:\WINDOWS\system32\drivers\etc\hosts file and uses it to block nasty sites
> with regular updates.
>
> The issue is that WinDefend detects SS's (apparent) access to the hosts file
> and puts up an alert. I say 'apparent' because the WinDefend messages do not
> identify the process or application involved. I will do more testing to be
> absolutely sure that if I turn off SS's use of the hosts file, the messages
> in WinDefend will go away, but the certainly began immediatly upon
> installation of SpySweper.
>
> I would like to ask the WinDefend folks if they have the means to detect
> Spysweeper's processes and identify them to avoid the appearance of this
> issue. One might ask why the need to run multiple programs for the same
> purpose but I'm sure that's one we could debate all evening. It just
> doesn't seem that one program does it all, yet.
>
> Rob

You could exclude the hosts file from scanning in advanced options (tools,
general settings, scroll down)--but that of course opens the hosts file to
manipulation by viruses, for example, which also use this file for their own
purposes.

--

"JRosenfeld" <(E-Mail Removed)> wrote in message
newsD25CBA4-AC51-4BCF-A6D8-(E-Mail Removed)...
> The problem is that Spysweeper reloads the hosts file at each restart and
> WD
> rightly alerts to a 'change' in the hosts file. If you use a different
> hosts
> file that is fixed, until you update it manually, there is no problem. I
> use
> mvps.org hosts file
> http://www.mvps.org/winhelp2002/hosts.htm
> They issue regular updates.
>
> "RobCoh" wrote:
>
>> Hi,
>> I have WinDefend B2 as well as Webroot SpySweeper (4.5.9 build 709)
>> installed on my XP Pro SP2 box. SpySweeper has a feature where it takes
>> over
>> the
>> C:\WINDOWS\system32\drivers\etc\hosts file and uses it to block nasty
>> sites
>> with regular updates.
>>
>> The issue is that WinDefend detects SS's (apparent) access to the hosts
>> file
>> and puts up an alert. I say 'apparent' because the WinDefend messages do
>> not
>> identify the process or application involved. I will do more testing to
>> be
>> absolutely sure that if I turn off SS's use of the hosts file, the
>> messages
>> in WinDefend will go away, but the certainly began immediatly upon
>> installation of SpySweper.
>>
>> I would like to ask the WinDefend folks if they have the means to detect
>> Spysweeper's processes and identify them to avoid the appearance of this
>> issue. One might ask why the need to run multiple programs for the same
>> purpose but I'm sure that's one we could debate all evening. It just
>> doesn't seem that one program does it all, yet.
>>
>> Rob

As Bill says, you can turn off the hosts file monitoring for unknown
changes.
WD will detect many host file hijacks by malware in scans, so you won't be
totally unprotected if you don't have unknown notifications on.

And finally, the only answer I can give to the Spysweeper compat problem is
that we're investigating.

Thanks for trying Windows Defender,
Joe

"Bill Sanderson" <(E-Mail Removed)> wrote in message
news:%23Z79I%(E-Mail Removed)...
> You could exclude the hosts file from scanning in advanced options (tools,
> general settings, scroll down)--but that of course opens the hosts file to
> manipulation by viruses, for example, which also use this file for their
> own purposes.
>
> --
>
> "JRosenfeld" <(E-Mail Removed)> wrote in message
> newsD25CBA4-AC51-4BCF-A6D8-(E-Mail Removed)...
>> The problem is that Spysweeper reloads the hosts file at each restart and
>> WD
>> rightly alerts to a 'change' in the hosts file. If you use a different
>> hosts
>> file that is fixed, until you update it manually, there is no problem. I
>> use
>> mvps.org hosts file
>> http://www.mvps.org/winhelp2002/hosts.htm
>> They issue regular updates.
>>
>> "RobCoh" wrote:
>>
>>> Hi,
>>> I have WinDefend B2 as well as Webroot SpySweeper (4.5.9 build 709)
>>> installed on my XP Pro SP2 box. SpySweeper has a feature where it takes
>>> over
>>> the
>>> C:\WINDOWS\system32\drivers\etc\hosts file and uses it to block nasty
>>> sites
>>> with regular updates.
>>>
>>> The issue is that WinDefend detects SS's (apparent) access to the hosts
>>> file
>>> and puts up an alert. I say 'apparent' because the WinDefend messages
>>> do not
>>> identify the process or application involved. I will do more testing to
>>> be
>>> absolutely sure that if I turn off SS's use of the hosts file, the
>>> messages
>>> in WinDefend will go away, but the certainly began immediatly upon
>>> installation of SpySweper.
>>>
>>> I would like to ask the WinDefend folks if they have the means to detect
>>> Spysweeper's processes and identify them to avoid the appearance of this
>>> issue. One might ask why the need to run multiple programs for the same
>>> purpose but I'm sure that's one we could debate all evening. It just
>>> doesn't seem that one program does it all, yet.
>>>
>>> Rob
>
>