Disable Single File On Demand Scanner

R

Rogertheshrubber

New member
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!!
 
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]
@=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" %*
​
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).
It would be interesting to know where they differ on machines where SDFiles.exe opens instead!
 
Last edited:
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 ;)
 
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/archive/2004/02/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:
Yes Doug, that is the most prudent course we see as well and we have adjusted the way we install SpyBot as well. Shame, it's a cool feature.

My hope is that we will be able to provide PepiMK with data that may be of some assistance to them. We are staunch supporters of the work being done and are only too pleased to be of any service what so ever.

For myself I must say that I am very pleased also by the level of professionalism I have encountered on this forum. Too many times these forums degrade into over blown chat rooms and it's hard to find real answers, I hate having to use them, this was an excellent experience.
 
Between some PE testing and 2.0 porting we played a bit with standard context menu enhancement DLLs. Works fine with 32 bit, haven't compiled a 64 bit version yet. It's in the form of a submenu now, so that we'll be able to place multiple items there without taking more space on the main page (e.g. the file "killer" and the shredder which some people wanted in the context menu). Now we just need a 12x12 small bitmap for the context menu and some testing whether the DLL implementation would avoid the auto-opening of the file scanner (from the documentation, I would say so). It also seems the DLL is only in memory when the context menu is opened, so it doesnt mean permanent additional memory wasting.
 
Lower Single File On Demand Scanner

Rogertheshrubber said:
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!!
Click to expand...

All I want to do is lower this in the right click menu, from the first choice, to the second, or third or whatever. I would still like to be able to use it.

When it's first on the list, it is what gets activated when programs are installed from the control panel. So, for msi files I need this behavior changed. Oddly it doesn't seem to be a problem for exe files. :sick:

Thanks.
 
You must log in or register to reply here.
Back
Top