Spybot-S&D 1.6, Release Candidate 1

@dj.turkmaster: in the final release it'll be registered by the intaller, no user interaction required.
I'll test the TeaTimer numbers... I could probably also add the LASSH count there...

But why did it decrease from about 80.000 processes to 1172 proccesses? Does this cause a problem with it's protection? And what about the updater, is it a bug?
 
Fatal Error Redux

1. Open Spybot, remove all immunization.

2. Open Control Panel, start process to remove Spybot; encounter, five or six times, an error message:

"Service `SBSD Security Center Service" failed to uninstall with error: "System Error: Code 1060. The specified service does not exist as an installed service."

After continually clicking on OK, uninstall process finally proceeds.

3. Restart computer, reinstall Spybot.

4. Reimunize.

5. Start scan process; when Spybot gets to Firefox 3 default profile bookmarks, Spybot again stops working.

6. Click on Stop, restart scan. Spybot stops at bookmarks.

7. After perhaps fifteen minutes, Spybot states that scan did not finish as it was stopped by user; that message appeared while Spybot was trying to scan the bookmarks the second time.

I had no problems whatsoever with the beta-test releases, but RC1 does not work for me.
 
@dj.turkmaster: if I had known back when I wrote it, I wouldn't have written that I need to test it ;)
Meanwhile I found the reason (the new file scanner that loads faster and has less memory print was managing the count differently) and have fixed it :)

Sorry about the updater, did miss the question. That has to do with the internal updater completely removed now (previously, it had been kept hidden as a backup method in case the stand-alone file would be causing problems).
First, people have been complaining that they behave differently, now people note that they behave the same :D
To be honest: I'm not absolutely sure what exactly is the optimal behaviour, but both doing the same seems to be more "consistent". You can still change the beta setting from the Settings page of Spybot directly, or you can run the updater form its start menu program group.

@Always Confused: please check whether you have SQlite3.dll in the Spybot-S&D folder; it's an essential file for Firefox 3 scanning. Also, could you check whether you have a file of the same name in the Windows folder maybe?
(just thinking about possible incompatible versions, though an application /should/ use the one in its own folder with priority by default, I'll have to check whether the SQLite code really does that)
 
@Always Confused: please check whether you have SQlite3.dll in the Spybot-S&D folder; it's an essential file for Firefox 3 scanning. Also, could you check whether you have a file of the same name in the Windows folder maybe?
(just thinking about possible incompatible versions, though an application /should/ use the one in its own folder with priority by default, I'll have to check whether the SQLite code really does that)

SQlite3.dll is in the Spybot--S&D folder (no version stated); copies also exist in Program Files\Mozilla Firefox (Version 3.5.4.1)and C:\Windows\Installer\$PatchCache$\xxxyyyzzz\etc, infinitum, et.al.
 
I've just downloaded and Installed Spybot 1.6 RC1 and I am glad to report that the Right Click, File Properties bug is gone:eek:. Nice One lads!!!!:bigthumb:
 
immunization database

I just installed Spybot 1.6 RC1, at the update, it updated the immunization database from 2007-07-25 (TU Braunschweig) is this a problem?

immunizationdatabase.jpg
 
As for opening more than one file, Windows actually calls the exe once for each file. Spybot-S&D itself is just passing its parameter along to an already running instance if one is found. So regardless whether you select more than one file at once, or one after each other, they'll all be loaded in the first visible window. Did you have another scanner window in the background maybe?

I can't figure out why this is happening. I'm now seeing it on three different XP SP3 systems. Unfortunately I pretty much install the same stuff on all my systems and configure them all the same way, so it's hard for me to figure out what might be causing this. But I don't have another scanner window running in the background, so I know it isn't that.

I actually used Process Monitor to create a log of everything Windows does when I select one file and the interface comes up as expected and another separate log of what happens when I select multiple files and it doesn't come up. The logs get massive so I could have missed something, but there are certainly no obvious errors (to me) when it fails. The only difference is that when I select a single file Explorer.EXE performs a "Process Create" with the PID detail showing:

"C:\Program Files\Spybot - Search & Destroy\SDFiles.exe" "{Drive}:\{PATH}\{filename}"

When I select multiple files, however, that process create never occurs (though all other SDFiles.exe related processes seem to). Nothing else happens either. I don't see any other process coming into play and interfering with SDFiles.exe - it just doesn't run from the context menu if multiple files are selected.

Just FYI, if I start selecting other individual files after the interface opens successfully it works fine. Each file I add just jumps into the already open instance - but only if I add them one at a time. If I try to add more than one at a time, it still fails even when the interface is already open (by which I mean the selected multiple files never appear in the list - the interface stays open though).

Oddly enough, I can select multiple files and pass them successfully to my AV scanner (ESET NOD32) via a context menu selection. I can also select multiple files and have them added to an archive (via 7-Zip, WinRAR, or WinZip) and cut/copy/paste/etc. multiple files. It's just SDFiles.exe that doesn't seem happy.

Any other ideas? This is driving me nuts.

Thanks again!

And thanks also for the [future] b/w-list status and folder context menus updates.
 
Last edited:
@Always Confused: interesting, didn't even look at the Firefox folder for SQLite3.dll yet I must admit ;) The DLLs that are officially distributed on the SQLite page do not have version resources. Could you please check which one gets loaded when Spybot-S&D runs? Spybot-S&D: Tools -> Process List -> SpybotSD.exe (list entry) -> Loaded modules (tab at the bottom) - sqlite3.dll (list entry there) -> Path (column).
If it is the one in the Spybot folder as it should be, could you please download the latest version ( http://www.sqlite.org/download.html , section "Precompiled Binaries For Windows, third one) and let me know whether that one works better?

Your steps mean that Firefox is not open at the time of the crash, right?

@Giga Wizard: forwarded to the person preparing the updates :) Most immunization stuff is part of the Detection rules: Supplemental update though, this might be some static part.

@Zer0 Voltage: thank you for making so much detailed tests :)
7-Zip, WinRAR and WinZip imho use system libraries loaded into the explorer process instead of the old, but easy method of HKEY_CLASSES_ROOT\*\shell\...
It might not do harm to, in the actual command, add a %* after "%1" (separated by a space).
I'm updating my clean XP VM to SP 3 now to test for myself on the same OS configuration...
 
when will spybot support multithreading for faster scan since nowadays, dual-core or even more processor is affordable? :)
 
Last edited:
@Zer0 Voltage: thank you for making so much detailed tests :)
7-Zip, WinRAR and WinZip imho use system libraries loaded into the explorer process instead of the old, but easy method of HKEY_CLASSES_ROOT\*\shell\...
It might not do harm to, in the actual command, add a %* after "%1" (separated by a space).
I'm updating my clean XP VM to SP 3 now to test for myself on the same OS configuration...

Thanks very much, I really appreciate you looking into it.

It did actually work on my 4th XP system which has SP2, so maybe SP3 does have something to do with it. I can't apply SP3 to the system in question since I still need an SP2 level system around, so I can't be sure. For the record, I also had no problems on multiple Vista systems (SP0 and SP1).

One more possibly interesting detail: on the systems showing the problem, I also cannot load multiple files into FileAlyzer using the "Analyse file with FileAlyzer" context menu option. Should that work? I never tried before... :)

I'll try to compare the HKEY_CLASSES_ROOT\*\shell\ trees on my working and non-working systems next - just in case.

Thanks again!
 
It might not do harm to, in the actual command, add a %* after "%1" (separated by a space).

I tried modifying the default key under HKEY_CLASSES_ROOT\*\shell\sdfiles\command as follows:

1. "C:\Program Files\Spybot - Search & Destroy\SDFiles.exe" "%1" %*
2. "C:\Program Files\Spybot - Search & Destroy\SDFiles.exe" "%1" "%*"
3. "C:\Program Files\Spybot - Search & Destroy\SDFiles.exe" %*
4. "C:\Program Files\Spybot - Search & Destroy\SDFiles.exe" "%*"

but none of those worked. :sad:

In fact, 3 and 4 don't even let you scan a single file (which would be expected, but I wanted to be thorough).

Works fine from a command line though - just not from the context menu entry.

It also doesn't look like SP3 is the problem - or at least not SP3 alone - since I installed it on a new XP SP3 VMware client and it worked there.

Even more confusing is that I installed it in yet another VMWare client that has all of the same software as one of the other clients where it didn't work - but in this client it did work! :hair:

I just can't find the difference between these systems.

Any luck on your end? Is there perhaps some way to enable a verbose log for Spybot-S&D that would log everything it does?
 
No logging exists in SDFiles.exe, and since you were already at the roots, noticing that no CreateProcess was called, I doubt it would even get anywhere where it could log something :-/

I do have silly bug on two machines here that might lead me somewhere. Whenever I select more than one file on those, Windows will first show the "Move Files", then the "Copy Files" dialog before continuing its operation. It still works afterwards, but it seems that when multiple files are selected, something else than the HKCR\*\shell\ handlers operates first and would only later chain back there.

Meanwhile I've just heard we've found another machine that can reproduce your problem, going to look at that one now :)
 
Yodama just found out that on his machine, this behaviour is not limited to Spybot-S&D. Even the default notepad.exe (right-click multiple .txt files and choose Edit) does not work on that one. Same behaviour on my two machines where I had that similar problem.

So could you please test with a few text files and the standard Edit operation please? If that doesn't work either, we'll of course continue to search for some option to fix it, but at least we know it does not have to delay the release since it's a global problem with Explorer settings probably, affecting all applications that use HKCR\*\shell\ (while context menu handlers are not affected, granted).

Update: renaming the folder HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers and restarting Explorer makes all other regular shell handlers work again.
 
RC1 on WinME

Looks good, opens properly on <app>/Spybot-S&D index page (no more open to <app>/Spybot-S&D/Settings page!) and holds a custom skin (unlike beta1) on load. Only a few minor anomalies for me in the interface:
1) <app>/Info & License/Statistics persistently shows (Last found, Last fixed) date as 991230 rather than the actual
2) the <app>/Settings/Settings page lacks a few of the selections previously available - in particular the /Look & Feel show/don't Headers checkbox. Not sure how to successfully edit the relevant ui file(s) ...
3) SDFiles is a rather nice mini, but did not show as a contextmenu item at first .. so I simply added a shortcut for it to the 'Send To' contextmenu(sub). Opens fine from there and the drag'n'drop accepts both folders and files.
4) Also perhaps the small remove-spybotsd-settings.reg might need some path modification ("Safer Networking Limited" rather than "PepiMK Software" for RC1). This may be more of a 'note' to users of RC1.

scantimes:
SSD v1.5.2.20 Immunizations=55323 scantime=18:37
SSD v1.6.0.25 Immunizations=72851 scantime=12:32
SSD v1.6.0.27 Immunizations=72851 scantime=14:13
(all) botchecks=171851
 
Last edited:
I'm actually relieved to hear that the context menu multiple file selection issue isn't limited to me. :D:

You are correct about Edit - that doesn't work for me either if selecting multiple files (on the affected systems). Hadn't tried that one before. :)

Renaming HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers and restarting Explorer did not fix anything for me. In fact, that only broke the "Send To ->" context menu entry and removed an entry for Unlocker.

Any other ideas?

I do have silly bug on two machines here that might lead me somewhere. Whenever I select more than one file on those, Windows will first show the "Move Files", then the "Copy Files" dialog before continuing its operation. It still works afterwards, but it seems that when multiple files are selected, something else than the HKCR\*\shell\ handlers operates first and would only later chain back there.

In a bizarre twist, I can actually help you with this one.

You see this behavior on systems where someone added "Copy To" and "Move To" entries to their context menu.

I put together some .REG files a while back to easily enable and disable this because of that very problem (which cannot be avoided if you want those extra context menu entries).

To fix it - which will remove the Copy/Move To context menu entries - create a .REG file with the following and merge it into the Registry:

REGEDIT4

[HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\Copy To]
@=-

[HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\Move To]
@=-

[HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers\Copy To]
@=-

[HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers\Move To]
@=-

[HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers\Copy To]
@=-

[HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers\Move To]
@=-

[HKEY_CLASSES_ROOT\AllFilesystemEditObjects\shellex\ContextMenuHandlers\Copy To]
@=-

[HKEY_CLASSES_ROOT\AllFilesystemEditObjects\shellex\ContextMenuHandlers\Move To]
@=-

[-HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\Copy To]

[-HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\Move To]

[-HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers\Copy To]

[-HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers\Move To]

[-HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers\Copy To]

[-HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers\Move To]

[-HKEY_CLASSES_ROOT\AllFilesystemEditObjects\shellex\ContextMenuHandlers\Copy To]

[-HKEY_CLASSES_ROOT\AllFilesystemEditObjects\shellex\ContextMenuHandlers\Move To]

Of course that assumes the added context menu entries were actually named "Copy To" and "Move To". If they were named something else, the .REG must be modified accordingly.

After merging that, you will see that those "Copy Files" and "Move Files" dialogs will be gone.

If you prefer to keep the Copy/Move To context menu entries, you can re-enable them by merging a .REG file with the following:

REGEDIT4

;All Files
[HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\Copy To]
@="{C2FBB630-2971-11D1-A18C-00C04FD75D13}"

;All Files
[HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\Move To]
@="{C2FBB631-2971-11D1-A18C-00C04FD75D13}"

;All Drives
[HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers\Copy To]
@="{C2FBB630-2971-11D1-A18C-00C04FD75D13}"

;All Drives
[HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers\Move To]
@="{C2FBB631-2971-11D1-A18C-00C04FD75D13}"

;All Files and Folders
[HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers\Copy To]
@="{C2FBB630-2971-11D1-A18C-00C04FD75D13}"

;All Files and Folders
[HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers\Move To]
@="{C2FBB631-2971-11D1-A18C-00C04FD75D13}"

;All editable Files and Folders
[HKEY_CLASSES_ROOT\AllFilesystemEditObjects\shellex\ContextMenuHandlers\Copy To]
@="{C2FBB630-2971-11D1-A18C-00C04FD75D13}"

;All editable Files and Folders
[HKEY_CLASSES_ROOT\AllFilesystemEditObjects\shellex\ContextMenuHandlers\Move To]
@="{C2FBB631-2971-11D1-A18C-00C04FD75D13}"

Then after merging that, run:

regsvr32 /i shell32.dll

Personally I no longer use those context menu entries because of those Copy/Move dialogs popping open when you do certain things. That was too annoying. So now I just use the built-in "Copy to Folder..." and "Move to Folder..." selections available from the Edit menu (in any folder's menu bar).
 
Last edited:
Fatal Error Redux 2

@Always Confused: interesting, didn't even look at the Firefox folder for SQLite3.dll yet I must admit ;) The DLLs that are officially distributed on the SQLite page do not have version resources. Could you please check which one gets loaded when Spybot-S&D runs? Spybot-S&D: Tools -> Process List -> SpybotSD.exe (list entry) -> Loaded modules (tab at the bottom) - sqlite3.dll (list entry there) -> Path (column).
If it is the one in the Spybot folder as it should be, could you please download the latest version ( http://www.sqlite.org/download.html , section "Precompiled Binaries For Windows, third one) and let me know whether that one works better?

Your steps mean that Firefox is not open at the time of the crash, right?
1. The .dll running with Spybot is the one in the Spybot folder.

2. Downloaded/installed the .dll from the URL you supplied.

3. Firefox closed while running Spybot.

4. Now, to the pertinent information from this morning's trials:

a. Started Spybot, told it to run a check; when I returned to the computer, Spybot had finished the check, with nothing to report.

b. Without restarting Spybot, I ran another check.

i. It took approximately six minutes to scan the disk, up to the point where Spybot started to scan the Firefox bookmarks file.

ii. It took approximately fourteen minutes for Spybot to scan the bookmarks file. I conclude that Spybot was likely not crashing with the original .dll installed but, rather, that as it was taking such an incredibly long time to scan the file, I thought it had crashed.

5. While I never actually timed the bookmarks scan with Spybot 1.6 b1 & b2, I estimate that it took less than two minutes to do that. Something quite bad has, apparently, changed between the two beta releases and the first release candidate of Spybot 1.6.

Fourteen minutes to scan the bookmarks file is unacceptable. I am rather certain that, if Spybot 1.6, when released, takes that long to scan Firefox 3 bookmarks files, there will be many Spybot users stating that Spybot 1.6 does not work.
 
Thank you for the details :)

Earlier beta versions didn't support Firefox 3 yet. But SQLite is a database format, contrary to the old HTML format, so it should be faster instead of slower than Firefox 2 support.

Yes, 14 minutes are unacceptable. I'll have to check where exactly the longest delay takes place; while SQLite is a database format designed for quicker data access, it's not like a full server-sided database, so it might help to do some of the heavier operations not on database engine side (I already optimized a bit there, but there might be more).

Thanks again for very useful information, I feel better now ;)
 
Back
Top