That sounds more like the Adobe Reader upgrade destroyed your proper .pdf extension handling than Spybot-S&D hijacking it.
What we've found so far:
- If you click an unassociated file with Windows XP 64 or later, Windows will ask you what to do with it.
- If you click an unassociated file with Windows XP 32 or earlier, unknown files will be opened with the first "all files" handler available.
By unassociating .pdf, we could reproduce this. But then, if .pdf is not asociated with any app, there's something wrong
Skip a few paragraphs now if you're not interested in the technical background.
The PDF association usually goes like this:
The key
HKEY_CLASSES_ROOT\.pdf\ has a
(Default) value saying
AcroExch.Document. This means the action taken when opening PDFs would be the one found in
HKEY_CLASSES_ROOT\AcroExch.Document\Shell\Open\Command\ , where the
(Default) value points to
"C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe" "%1" or similar.
Well, actually it's designed even more complex; the
(Default) in
HKEY_CLASSES_ROOT\AcroExch.Document\CurVer\ forwards, being set to
AcroExch.Document.7, handling to
HKEY_CLASSES_ROOT\AcroExch.Document.7\shell\ , where you'll see the (Default) verb
Read, which means that the command in
HKEY_CLASSES_ROOT\AcroExch.Document.7\shell\Read\command\ will be executed by default for PDFs.
Breaking any value in that chain from .pdf (open) to AcroExch.Document (open) to AcroExch.Document.7 (read) will indeed open a PDF with Spybot (because it could not find the intended app ah the end point of that chain). But that would be the case just because MS intended unassociated apps to be opened with the first all-filetypes handler.
Thinking about workarounds, the only one we've found would be to adjust the registry to behave on XP 32 and earlier to something that is used in XP 64 and later.
Downside: changing this behaviour would also affect other applications that have handlers for all file types. Users my find that mich more annoying than the current situation that happens with broken file associations "only".
A method to reduce this would be to apply that patch only if Spybot-S&D is the only all-files-handler using the "shell" entry (packers often use "shellex" which has the downside of working only half of the time on 64 bit machines
), but that would not deal with situations where other apps might be installed at a later point.
Microsoft does not seem to have offered a method to list items that are not to be used to open an unassociated file (
see this MSDN page).
So, to sum it up: right now it looks very much like a broken Adobe Reader update and not Spybots fault. And that's where "the damn fix should be in Spybot" is not true any more, because it would mean changing either Windows default behaviour (which would annoy many more users) or give up a feature because it irritates the user in case his system is broken (which imho is no an option either).
