Disable Single File On Demand Scanner
How do I disable the On Demand Single File Scanner feature in SD 1.6.0? It is interfering with the use of installation files stored on our wiki page. Instead of the install running this scanner runs on the file but the install never begins. This results in a lot of calls from our non-tech-savvy employees slowing things down and defeating the purpose of having the files on our wiki to begin with. Help!!
Rogertheshrubber:
To disable the "Scan using Spybot-Search&Destroy" right click context menu feature in Spybot 1.6:
- Delete the following registry keys:
--- or ---Code:HKEY_CLASSES_ROOT\*\shell\sdfiles HKEY_CLASSES_ROOT\Folder\shell\sdfiles
- See this post by Zer0 Voltage in:
- Spybot 1.6 questions
http://forums.spybot.info/showthread.php?t=30678
Getting an answer is one thing, learning is another.
Microsoft Windows XP Home Edition running on a 2.40GHz Intel® Pentium® 4 Processor with 512 MB of RAM and a 533 MHz System Bus.
What kind of files would that be?
Which association do they have?
How is the association linked to which app?
Just remember, love is life, and hate is living death.
Treat your life for what it's worth, and live for every breath
(Black Sabbath: A National Acrobat)
Mostly .msi files PepiMK. We keep frequently used installation and configuration file on our wiki to simplify our jobs allowing the user to just click and run when they need something.
Not sure I understand the question "How is the association linked to the app?" can you tell me what your looking for?
Ah Ha!
Thanks MD USA, that was what I was thinking. I read your suggested thread and that is exactly what I was afraid I'd find, that only in the install did you have the choice to turn this feature off. Could be much worse though.
I have made the notes available to our folks and we will disable this feature on furture installs.
I should note here that this is only a problem for us because we want to run these .msi files in place and not have people have to download them first. It is a convenience issue for us and a simplicty issue for the users, many of whom are easily lost...
Thanks again.
The Single File Scanner is associated with "all files", but not with a particular file type. If a particular file type has an application associated with it, Windows should choose that associated application.
.msi for example should be associated with the Windows Installer, through the following registry entries:[HKEY_CLASSES_ROOT\.msi]These settings (rough draft, not exact copy as for quotes etc.) make sure that .msi files are opened with Windows installer, and are system default on Vista seen as above, and the same on XP 64 (haven't checked older ones right now).
@=Msi.Package
[HKEY_CLASSES_ROOT\Msi.Package]
@=Windows Installer Package
[HKEY_CLASSES_ROOT\Msi.Package\shell]
@=Open,Repair,Uninstall
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open]
@=&Install
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open\command]
@="%SystemRoot%\System32\msiexec.exe" /i "%1" %*
It would be interesting to know where they differ on machines where SDFiles.exe opens instead!
Last edited by PepiMK; 2008-10-22 at 20:41.
Just remember, love is life, and hate is living death.
Treat your life for what it's worth, and live for every breath
(Black Sabbath: A National Acrobat)
And those associations remain intact on our systems. Perhaps if I described the actual action occuring when this takes place...
File "A" is stored on our wiki site.
User clicks link to file "A" and IE presents a dialog asking if you wand to Run or Save.
User clicks Run and then the file scanner opens and scans the file twice.
User clicks the Close button on the scanner window, window closes, nothing else happens.
OR...
User clicks on Save, file saves to given location, User clicks Open, file scanner opens and scans the file twice.
User clicks the Close button on the scanner window, window closes, nothing else happens.
OR...
User clicks on Save, file saves to given location, User double clicks on the file, file scanner opens and scans the file twice.
User clicks the Close button on the scanner window, window closes, nothing else happens.
Repeats 100% of the time. Have to right click on the file and from the context menu select install, then the file runs correctly.
The whole thing surprised me actually because we have had so few problems with SpyBot over the years, you get used to it not interfering. This is just annoying though, because so many users get totally stymeed because of this.
It does not seem to affect .exe files this way, only the .msi files that I have seen. There was a report from a user that it was doing this to "Everything I tried to open" but that does not seem to be true.
I'd be happy to research this further with you if you wish, just tell me what you'd like to know and I'll look into it.
To be honest, right now I'm unsure as to where to investigate further. We were able to reproduce a very similar problem (PDFs) only by breaking the chaining scheme I highlghted above, and no other way. Is this XP 32 or earlier (not XP 64 and Vista) only?
The browser thing might be a clue... browsers decide on MIME types, which can be defined in the registry as well, aybe we should investigate MIME type problems instead of file extensions. MSI does not have a specific MIME type, but do you by chance know which one the server uses for these files (NetAlyzer with HEAD on the URL would report that as Content-Type)?
Well, in the worst case we'll opt for a context menu DLL instead of the direct registry path to appear in Explorers context menu.
I've always favored the classical registry-only approach because it didn't mean additional code running (hooked into Explorer) and works on 32 as well as 64 bit without special handling, but well, at least for 2.0 we might have to evaluate that option againü and 300 KB more loaded into Explorer would not be as bad as years ago
Just remember, love is life, and hate is living death.
Treat your life for what it's worth, and live for every breath
(Black Sabbath: A National Acrobat)
Well, I'm not sure of course but it looked like NetAlyzer said it was text/HTML.
Systems are all Windows XP 32 running SP3, so the chaining you quoted appears to be the same in our older OS as in your quoted Vista machine. I have seen the same problem on Windows 2000 machines as well but there are not many of those left at this point.
I am honoured to have produced a real head-scratcher problem but at the same time it is frustrating. The work around appears to be reinstall the product and be sure this feature is turned off. I hope I can provide you enough info to find an actual fix for the problem though.
A number of threads on this forum have raised this problem for several different - apparently random - filetypes. Many are titled cryptically and just ask how to disable the Spybot right click (context menu) option - and are happy with the registry hack or the uninstall and reinstall fix.
It appears that the Spybot context menu option is just falling foul of a problem in the Windows 2000/XP context menu handler. As PepiMK has said (in another thread) if no explicit default handler is configured the first available option that declares it deals with the "Open" request jumps in and tries to perform.
Microsoft themselves encountered this problem with the popular TweakUI context menu options "Copy To Folder" and "Move to Folder" - which stopped working correctly under XP (and 2000?) having worked fine under W98. You can read the about this similar issue at the following sites http://windowsxp.mvps.org/movetocontext.htm
http://blogs.msdn.com/oldnewthing/ar.../02/66160.aspx
I have stopped installing the context menu option on XP systems as a precaution - as there is no way to test if it is going to work correctly with all installed filetypes.
Last edited by DougCuk; 2008-10-24 at 14:33.
Reply With Quote
