View Full Version : How do one give feedback on the latest beta ?

2007-11-15, 21:52

How does one give feedback on he latest beta ?

I'm now running the and it is much, much better that or

However, it does seem to be quite right. I've installed it on two systems running Windows 2000 SP4 etc. and both occasionally appear to freeze for what is subjectively a long time just as with the earlier versions but not as often.

As far as I have been able to determine, I think services.exe is hogging the CPU, Spybot isn't actually running but TeaTimer is.

Is there another beta in the works ? If not, I'm going back to SpyBot 1.4.

Next question is why am I not allowed to post replies ? I've seen yet another post by someone asking why their PC is acting slow and weird and I just wanted suggest they try the latest beta.

The organisation of your web-site is such it took me a considerable amount of time to work out that was what I should do when I first hit the problems and I got .16 instead of .17.

I first saw a post by someone else who found immunisation was taking for ever (for me, tens of minutes of CPU). The person who made the post was very concerned that they themselves had done something very wrong. Your moderator's response completely missed the point by discussing the pros and cons of immunisation and did not admit that SpyBot wasn't working as well as one might wish.

Keep up the good work, don't let little mistakes spoil it all.

2007-11-16, 10:33
Well, the beta forum is a good place for beta feedback ;)
No idea why you can't post replies, the button to reply is to the left, above and below each thread :)

Regarding immunization and missing the point, I don't know which topic you refer to, but it sounds a bit like the point was not missed at all: some immunization features are now compared to 1.5, and those may slow down the system. If it's services.exe, it might be the hosts file immunization. Since you can toggle single on or off immunizations in 1.5, that should be easy to test.
Sure, stepping back to 1.4 will no longer offer the new immunization features 1.5 offers, but also has other features missing, so deciding what to immunize is probably the better way.

2007-11-17, 01:05
Thanks for the suggestion Pepi re the host immunisation. Here's more info you might find useful.

System 1 - AMD Sempron 2.6 GHz, 512 Mb RAM, MS Windows 2k Pro SP 4

Invoke Spybot. Progress bar comes up, fills up and then system pauses. At first mistaken for check online for updates. Task Monitor used to 'determine' CPU seconds used: SpyBot S&D circa 15 seconds CPU, services.exe circa 30 seconds CPU.

Hosts file is immunised. Uncheck all but hosts and click the undo button. services.exe locks up system for circa 30 seconds. On return Spybot still reports 7500 protected in hosts. In the advance section SpyBot still shows a very full hosts files. Click undo again. services.exe locks up etc. Try cat /etc/hosts under cygwin and services.exe etc.

Eventually something seems to cause a flush of the hosts table to disk and cat /etc/hosts shows no Spybot entries, SpyBot immunisation reports 7500 unprotected and, in the advanced section, it shows the host file as practically empty.

Now SpyBot startup is much quicker - services.exe does not lock up system for circa 30 s.

This system seen to lock up during DVD playback since upgrade to SpyBot 1.5. Will see if problem recurs now that the hosts immunisation has been removed.

System 2 - P IV clone 450 MHz, 256 Mb RAM, MS Windows 2k Pro SP 4

SpyBot startup not affected by hosts immunisation.

During the removal the of hosts immunisation, service.exe used over 2¼ minutes of CPU. Then cat /etc/hosts forced a flush which required at least another 30 s CPU.

This system seen to lock up after pressing ctrl-alt-del to come of screen lock since upgrade of SpyBot to 1.5. Will see if problem recurs now that the hosts immunisation has been removed.

Now a question Pepi,

By default, SpyBot will immunise hosts and Firefox. The former appears to lock my systems for a ridiculous periods of time, the latter crippled Firefox (Java Scripts timing out).

Are you telling me that since the immunisation is something I don't have to do, then I have no good reason to blame SpyBot if my systems appear to be crippled as a result ?

Perhaps some other programs that use services.exe to examine the host file are more directly responsible for the crippling. The other security s/w on the systems in question is: AVG 7.5 Free Edition, Comodo and, on System 1 only, Online Armour Security Suite but only the Program Guard component.

A final query ...

... should I open a new thread to report that SpyBot S&D causes System 1 to power off part way through a scheduled scan ? :sad:

2007-11-19, 01:18
Slowing of network access with Windows 2000 and a large Hosts File is a known issue. See some of the following articles for an explanation of the DNS Client and caching issues.


I've had these same issues with my hosts file on an older PII 400MHz Windows 2000 system.

Your note about a System 1 power off during scanning is likely due to processor overheat causing a protective shutdown. This is becoming a more common issue with older systems especially that have both heat sinks and fans becoming clogged with dust. Spybot and some other scanning products like Antivirus can expose this since they often operate the processor at high utilization for extended periods, which few other programs can maintain.


2007-11-20, 17:04
Ditto Bitman's assessment with following:


1. Windows 2000 Service Pack 4 with all hot fixes installed by automatic update.
2. Spybot version
3. Internet Explorer 6 sp1 with all hot fixes installed by automatic update.

Problem symptoms:
1. Sluggish response to user requests. Even “Task Manager” slow to load/respond.
2. Services.exe consuming CPU 99% in what initially seem to be random pattern. However, started noticing problem initiation when using Windows Explorer. Finally, always occurs when network cable is removed then reinserted into router.
3. Multiple consecutive instances of the following message in the System Event Log:
“Timeout (30000 milliseconds) waiting for a transaction response from the Dnscache service. “
4. Longtime Spybot 1.4 user without incident. Problem first surfaced shortly after installing new Spybot version and installation of some recent patches to IE 6 and OS.

Problem Resolution:
1. Checked recent virus and spyware scans – none detected.
2. Reviewed Spybot forum. Found an interesting entry whose subject contained Services.exe and CPU 100%. However, individual indicated they had malware and discussion failed to focus on another cause. Then I found this one by searching the entire body instead of just subject.
3. Googled “dnscache services cpu spybot” and reviewed web postings in following forum thread: http://www.pcreview.co.uk/forums/thread-2067541.php.

Problem attributed to large number of entries in Hosts added by Spybot to foil navigation to known malware sites.

4. Replaced the Spybot updated Hosts file with original version and performed network cable remove & reinsertion to router – system functioned normally – Services.exe failed to spike CPU usage. Problem hasn’t recurred since.

Note – Might wish to have TeaTimer monitor Hosts file for change as this would signal attempts by malware to affect web surfing navigation to problem sites.

5. Looking to alter cache settings to accommodate Spybot list without causing CPU spike.


2007-11-23, 00:27
Many thanks Bitman :bigthumb:

I had seen the posts re large host files and the DNS client service on W2k slowing down dial up Internet connections. The description didn't fit my symptoms but I tried it anyway before I saw your reply.

It may be a known problem but it could do with someone making more of an effort to make it a more widely known problem. Neither "host file" nor "DNS client" come up with anything when typed into the SpyBot FAQ search. :red:

On System 1 I had only had trouble with scheduled scans, not with on-demand scans so I didn't tumble immediately to a fan problem. Opened the case, saw fan not working :eek:, got a new one, scheduled scan works.

Once again, many thanks.