You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Resident SDHelper slow in 1.6
- Thread starter Geraud
- Start date
I downloaded Spybot 1.6 and it killed my Internet Explorer. It was running so slow I had to finally download Firefox just to make it through the day.
It wasn't just the web browsing (images loading, etc) that slowed to a painful crawl, the whole Internet Explorer interface would freeze, preventing me from selecting toolbar items, tabs, even the url.
After reading these threads I disabled SD Helper and Internet Explorer is back to normal.
I noticed Windows Explorer was effected as well.
Interesting observation was when doing a Ctrl-Alt-Del and going to the Task Manager and viewing Processes iexplore.exe had a Mem Usage of around 125,000K, something I've never seen from any program. Upon disabling SD Helper it's back to a more reasonable 28,384K.
I'm running Windows XP Service Pack 3, IE7 and had no issues with Spybot 1.5
It wasn't just the web browsing (images loading, etc) that slowed to a painful crawl, the whole Internet Explorer interface would freeze, preventing me from selecting toolbar items, tabs, even the url.
After reading these threads I disabled SD Helper and Internet Explorer is back to normal.
I noticed Windows Explorer was effected as well.
Interesting observation was when doing a Ctrl-Alt-Del and going to the Task Manager and viewing Processes iexplore.exe had a Mem Usage of around 125,000K, something I've never seen from any program. Upon disabling SD Helper it's back to a more reasonable 28,384K.
I'm running Windows XP Service Pack 3, IE7 and had no issues with Spybot 1.5
spybotsandra
New member
Hello,
Those problems could probably be refered to the domains which are too much for the browser to handle when Spybot's resident feature is turned on. But we will delete the inactive domains soon and only deal with the ones that are really online. So the browser should work quicker then. We hope that we will solve this problem very soon.
Best regards
Sandra
Team Spybot
Those problems could probably be refered to the domains which are too much for the browser to handle when Spybot's resident feature is turned on. But we will delete the inactive domains soon and only deal with the ones that are really online. So the browser should work quicker then. We hope that we will solve this problem very soon.
Best regards
Sandra
Team Spybot
Thanks for the input spybotsandra.
But I have a question - would your theory about the large number of domains now in the protection list also explain the slowdown/delay seen when opening folders in My Computer? I can understand how this idea could explain a slowdown in IE Browser response but am unclear how it could affect the opening of folders in Windows Explorer.
The opening post in this thread stated:
The majority of posts in this thead relate to delay in opening folders in My Computer/Windows Explorer - with another set of people also reporting a dramatic slowdown in IE7 response times. Only a few people seem to report suffering both problems - I only have the Windows Explorer delay myself - IE7 is fine.
But I have a question - would your theory about the large number of domains now in the protection list also explain the slowdown/delay seen when opening folders in My Computer? I can understand how this idea could explain a slowdown in IE Browser response but am unclear how it could affect the opening of folders in Windows Explorer.
The opening post in this thread stated:
I think it is affecting Explorer and IE. All I have to do is click on "My Computer" and it takes about two seconds to open the folder for viewing. If I just disable SDHelper, the folder opens instantly.
The majority of posts in this thead relate to delay in opening folders in My Computer/Windows Explorer - with another set of people also reporting a dramatic slowdown in IE7 response times. Only a few people seem to report suffering both problems - I only have the Windows Explorer delay myself - IE7 is fine.
Upgraded automatically a few days ago the the new 1.6 engine and immediately opening folders in windows explorer slowed down to a 3 second delay. My browser also seemed much much slower. Since the only thing I had done was upgrade Spybot I just uninstalled it and my system seems normal again.
If I re-installing 1.5 and hoping for the best.
If I re-installing 1.5 and hoping for the best.
Those problems could probably be refered to the domains which are too much for the browser to handle when Spybot's resident feature is turned on.
Are there that many more domains protected through Spybot 1.6 compared to an updated version of Spybot 1.5.2 ? Because there is ABSOLUTELY NO slowdown in 1.5.2.
Also, as DougCuk brings up in his important question, I also experienced severe slowdowns just navigating folders in 1.6. -not so when I downgraded back to 1.5.2.
George69: you'll probably find going back to version 1.5.2 will be fine.
Last edited:
Greyfox made some interesting observations in this parallel thread
http://forums.spybot.info/showthread.php?t=30975&page=3
I just tested his suggestion about disabling SDHelper totally or just in the IE Manage Addons - and observed an interesting result. My problem is purely a 3 second delay opening folders in Windows Explorer - however both methods of disabling SDHelper remove this 3 second delay. I have tested this with two configs - XP-Pro_SP3 + IE7 and XP-Pro_SP2 + IE6 both react the same.
I know several other members have reported curing the IE slowdown via either route - but I was suprised the Manage Addons route cured my Windows Explorer delay - although I suppose they are functionally the same. But how a BHO that is only supposed to load when you start IE can affect the operation of Windows Explorer/My Computer - when IE is not running - is puzzling and the reason I feel we need some more technical input from the developers.
http://forums.spybot.info/showthread.php?t=30975&page=3
I just tested his suggestion about disabling SDHelper totally or just in the IE Manage Addons - and observed an interesting result. My problem is purely a 3 second delay opening folders in Windows Explorer - however both methods of disabling SDHelper remove this 3 second delay. I have tested this with two configs - XP-Pro_SP3 + IE7 and XP-Pro_SP2 + IE6 both react the same.
I know several other members have reported curing the IE slowdown via either route - but I was suprised the Manage Addons route cured my Windows Explorer delay - although I suppose they are functionally the same. But how a BHO that is only supposed to load when you start IE can affect the operation of Windows Explorer/My Computer - when IE is not running - is puzzling and the reason I feel we need some more technical input from the developers.
Terminator
New member
I thought I had cured my slowdown/crash problems by resetting IE but it didn't work:sad: so now back to disabling The SD helper untill it is fixed.
Greyfox - has again made an interesting suggestion in this parallel thread
http://forums.spybot.info/showthread.php?t=30975&page=3
He suggested running a test by renaming the Domains.sbs file which contains the bulk of the protection list used by SDHelper. The idea being if it only has a few items to protect it might speed up dramatically. And prove or disprove Spybot Sandras suggestion that the size of the list is the cause of problems with SDHelper. It nomally shows 18,879 entries but this reduces to 627 if it can't find the Domains.sbs file.
I tried renaming Domains.sbs and rebooted to ensure the change was active - but it had no effect on the 3 second delay seen in Windows Explorer. I then extended the idea to ALL immunisations - and it had no effect at all - the 3 second delay remained. But disable SDHelper and the delay is instantly gone.
Watching in Task Manager the CPU usage of Explorer jumps to 50% and stays there during the 3 second delay - but only shows a momentary spike when SDHelper is disabled. Without SDHelper the CPU usage in Task Manger (Performance graph tab) appears to reduce when you revisit the same folder again (caching?). You see the spikes on the graph get smaller - but with SDHelper running the CPU usage always rises to exactly 50% stays there for 3 seconds and then falls back to zero.
It would appear SDHelper is causing Explorer to get stuck - doing what I have no idea - any suggestions as to how to track this down? I have various utilities including Sysinternals Process Explorer but am not sure what to look for. Just had a first look and Sysinternals Process Explorer v11.04 does actually allow you to see that it is the BROWSEUI.DLL thread that accounts for all the CPU usage of Explorer during the 3 second delay. That might be an important clue to the right person?
http://forums.spybot.info/showthread.php?t=30975&page=3
He suggested running a test by renaming the Domains.sbs file which contains the bulk of the protection list used by SDHelper. The idea being if it only has a few items to protect it might speed up dramatically. And prove or disprove Spybot Sandras suggestion that the size of the list is the cause of problems with SDHelper. It nomally shows 18,879 entries but this reduces to 627 if it can't find the Domains.sbs file.
I tried renaming Domains.sbs and rebooted to ensure the change was active - but it had no effect on the 3 second delay seen in Windows Explorer. I then extended the idea to ALL immunisations - and it had no effect at all - the 3 second delay remained. But disable SDHelper and the delay is instantly gone.
Watching in Task Manager the CPU usage of Explorer jumps to 50% and stays there during the 3 second delay - but only shows a momentary spike when SDHelper is disabled. Without SDHelper the CPU usage in Task Manger (Performance graph tab) appears to reduce when you revisit the same folder again (caching?). You see the spikes on the graph get smaller - but with SDHelper running the CPU usage always rises to exactly 50% stays there for 3 seconds and then falls back to zero.
It would appear SDHelper is causing Explorer to get stuck - doing what I have no idea - any suggestions as to how to track this down? I have various utilities including Sysinternals Process Explorer but am not sure what to look for. Just had a first look and Sysinternals Process Explorer v11.04 does actually allow you to see that it is the BROWSEUI.DLL thread that accounts for all the CPU usage of Explorer during the 3 second delay. That might be an important clue to the right person?
Delay Opening Folders Caused by SDHelper Solved!!
This problem was really bugging me so I got serious.
I downloaded the Microsoft Sysinternals Process Monitor utility and tracked down what Windows Explorer was doing during the 3 second delay when opening a folder. This utility allows you to see in real time what your computer is doing - Registry operations - File-system operations - Processes and Thread operations. Not that I understand most of what it show - but what I found was unmistakable.
To cut a long story short - with SDHelper running Windows Explorer/My Computer spent several seconds checking the Cookies folder and did so for every change of folder. Clearing the Cookies folder removed the delay.
I am not in the habit of clearing my Cookies folder - I remove the ones flagged as Spyware but leave the rest - and it was never a problem under Spybot v1.4 or v1.5 - but Spybot v1.6 obviously reacts badly to excessive numbers of cookies. Not sure how many cookies it takes to cause a noticeable delay but I had around 2,300 cookies on one pc and 3,100 on the other and was seeing approximately a 3 second delay on both computers.
Process Monitor showed that each time you Open a folder in Windows Explorer (with SDHelper running) you see thousands of requests called "Query_Standard_Information_File" which was accessing the file "C:\Documents and Settings\{username}\Cookies\index.dat". The log revealed that my system made just over 6,500 identical requests to access the Index.dat file during the 3 second delay - which stopped anything else from happening. Disable SDHelper and these requests do not happen - and the folder contents displays instantly.
Something has changed in the way SDHelper interacts with Windows Explorer in the current version of Spybot.
Spybot v1.5.2 did not suffer this problem - this is new to Spybot v1.6
I first suspected it was the size of the Index.dat file (700KB) that was causing the problem - as this Index file never gets trimmed back when you delete cookies. But it is actually the number of cookies that causes the delay in Windows Explorer - just using the Delete Cookies option works even though the Index.dat file remains the same size.
So clear your Cookies folder and hopefully you too can use Spybot v1.6 with SDHelper enabled.
Sysinternals Process Monitor Links:
http://technet.microsoft.com/en-gb/sysinternals/default.aspx
http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx
Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity.
This problem was really bugging me so I got serious.
I downloaded the Microsoft Sysinternals Process Monitor utility and tracked down what Windows Explorer was doing during the 3 second delay when opening a folder. This utility allows you to see in real time what your computer is doing - Registry operations - File-system operations - Processes and Thread operations. Not that I understand most of what it show - but what I found was unmistakable.
To cut a long story short - with SDHelper running Windows Explorer/My Computer spent several seconds checking the Cookies folder and did so for every change of folder. Clearing the Cookies folder removed the delay.
I am not in the habit of clearing my Cookies folder - I remove the ones flagged as Spyware but leave the rest - and it was never a problem under Spybot v1.4 or v1.5 - but Spybot v1.6 obviously reacts badly to excessive numbers of cookies. Not sure how many cookies it takes to cause a noticeable delay but I had around 2,300 cookies on one pc and 3,100 on the other and was seeing approximately a 3 second delay on both computers.
Process Monitor showed that each time you Open a folder in Windows Explorer (with SDHelper running) you see thousands of requests called "Query_Standard_Information_File" which was accessing the file "C:\Documents and Settings\{username}\Cookies\index.dat". The log revealed that my system made just over 6,500 identical requests to access the Index.dat file during the 3 second delay - which stopped anything else from happening. Disable SDHelper and these requests do not happen - and the folder contents displays instantly.
Something has changed in the way SDHelper interacts with Windows Explorer in the current version of Spybot.
Spybot v1.5.2 did not suffer this problem - this is new to Spybot v1.6
I first suspected it was the size of the Index.dat file (700KB) that was causing the problem - as this Index file never gets trimmed back when you delete cookies. But it is actually the number of cookies that causes the delay in Windows Explorer - just using the Delete Cookies option works even though the Index.dat file remains the same size.
So clear your Cookies folder and hopefully you too can use Spybot v1.6 with SDHelper enabled.
Sysinternals Process Monitor Links:
http://technet.microsoft.com/en-gb/sysinternals/default.aspx
http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx
Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity.
Last edited:
Good find Doug,
Your findings also probably answer why I have never experienced this problem. All my computers are set to clear out the temporary internet files folder at the end of each session (IE7->Tools->Advanced->Security section->Empty temporary Internet files folder when browser is closed). In addition they also use 3rd party cookie control software to restrict cookies to a very small "allowed" list. (after exit from the browser index.dat is around 32K)
I also keep Spybot's normal file set so it "scans for usage track checks only" and after any on line session involving internet banking or other secure transactions run a quick scan and delete all tracking entries found (except for those items I have specifically excluded). I generally only do one full (all available checks) scan per week after updating.
Hopefully your find will solve the problem for many users.
Your findings also probably answer why I have never experienced this problem. All my computers are set to clear out the temporary internet files folder at the end of each session (IE7->Tools->Advanced->Security section->Empty temporary Internet files folder when browser is closed). In addition they also use 3rd party cookie control software to restrict cookies to a very small "allowed" list. (after exit from the browser index.dat is around 32K)
I also keep Spybot's normal file set so it "scans for usage track checks only" and after any on line session involving internet banking or other secure transactions run a quick scan and delete all tracking entries found (except for those items I have specifically excluded). I generally only do one full (all available checks) scan per week after updating.
Hopefully your find will solve the problem for many users.
Thanks Greyfox - it took some persistance to find.
I too keep my Internet Cache files under strict control but have never encountered an issue with the Cookies folder before - this is a new problem with Spybot v1.6 that didn't occur under v1.5
The other conclusion from this solution is that we did indeed have two seperate SDHelper issues.
The slowdown of the IE7 browser caused by SDHelper - that others have reported - must be due to a different as yet unknown quirk of Spybot v1.6 - as I have never observed this problem on my system. Does make me wonder if SDHelper is bogging down on some other folder somewhere that some users do not clear.
The large Domains List theory suggested by Spybot Sandra appears to be looking unlikely as a cause but we could do with some more testers - see here: http://forums.spybot.info/showthread.php?t=30975&page=4
I too keep my Internet Cache files under strict control but have never encountered an issue with the Cookies folder before - this is a new problem with Spybot v1.6 that didn't occur under v1.5
The other conclusion from this solution is that we did indeed have two seperate SDHelper issues.
The slowdown of the IE7 browser caused by SDHelper - that others have reported - must be due to a different as yet unknown quirk of Spybot v1.6 - as I have never observed this problem on my system. Does make me wonder if SDHelper is bogging down on some other folder somewhere that some users do not clear.
The large Domains List theory suggested by Spybot Sandra appears to be looking unlikely as a cause but we could do with some more testers - see here: http://forums.spybot.info/showthread.php?t=30975&page=4