S
Stamos
The right key on all folders is not working in sp2
D
Don Taylor
Stamos said:
There have been a string of folks reporting very similar problems
to what you are reporting. Some find that anything which uses
Windows Explorer (Recycle bin, folder shortcuts, control panel,
etc) all have a similar problem. Some find that right clicks are
their major problem. Some find any click. Some find it crashes
on open. Some find it refuses any clicks. There are some claims
but I've been scanning the thousands of postings on SP2 and I don't
think you will find any with "the fix" for this, at least yet.
But, some find it will work when you boot in safe mode.
And, some find it will work when you create a new user and switch
to that user to try it.
Some claim it is all spyware and viruses but I haven't seen any
posting that confirmed this for the Windows Explorer problem.
Some claim it is Divx or Spy Sweeper installed that is responsible
for this but others have it, don't have those and some seem to have
those and have no problem.
Some claim it is "ShellExtensions", little accessory gadgets that
sort of script extra cute features. The advice for that is to
install free ShellExView and to try (carefully) disabling these
features one at a time, if turning one off doesn't do anything then
turn it back on and try again. I did that with all 75 at once and
it made no difference at all.
You can escalate to Microsoft, go to
support.microsoft.com/windowsxpsp2
and give them all the details and clues and patterns you can find.
There is no guarantee that their analysis or directions will be
correct or even not make it worse. They told me I must "have some
corrupted files, repair windows back to install state and then
reinstall SP2 twice while in Safe mode." Before I did that someone
posted the "switch user" workaround that let me get by temporarily.
I sent email saying that if it worked for one user then it seemed
less likely it was "some corrupted files" and asked if they still
wanted me to blow windows away. They have not reponded to that in
a number of days now. But I can imagine what it is like inside now.
I hope this helps. If you try something and it doesn't help then
please make a posting so we can start accumulating what suggestions
don't do any good.
C
cquirke (MVP Win9x)
That would be shell integrations...
....whereas that would be mouse settings, perhaps?
Could be either shell integrations or 3rd-party mouseware...
....as could that. In both cases, it works because you are avoiding
troublesome settings or extra software.
Malware does tap into the OS, and sometimes uses shell integrations,
so yes that's a good call
Yes, ShellExView would be what I'd try, straight after a formal virus
check and trisl of MSConfig startup item suppression.
I don't know whether malware rootkits would suppress the info that
ShellExView pulls and uses.
Error Messages Are Your Friends
C
cquirke (MVP Windows shell/user)
I've seen these sort of issues from time to time, but I haven't seen
them as a function of being pre-SP2 or SP2. There are SP2 issues, but
so far I haven't read about this as being one of them.
That points firmly towards 3rd-party software.
Malware is badly-written 3rd-party software you didn't know you had,
so it's firmly in the frame there.
That points towards user-level integration, and away from the OS and
its Service Packs (as the OS and SPs are system-wide in scope).
Malware that integrates via HKCU rather than HKLM would be in the
frame too. Before XP, shell integrations and file associations were
system-wide, but XP allows a per-user overlay, so that interpreting
HKCR becomes more difficult and may not be enough.
Before XP, HKCR was a true alias of HKLM\..\Classes, but now it's a
combination of HKLM\..\Classes and HKCU\..\Classes - so if you suspect
a per-account attack on the shell, you should check both of these
directly rather than try and figure it out from HKCR.
Malware can use shell integration, but most don't. Most malware
prefer system-wide HKLM integration to per-user, but a countering
trend is the search for less familiar integration points to exploit.
Anything that integrates into the shell can do this; think
thumbnailers, device file transfer tools, archivers, av, anything that
wants to be part of the UI elements you describe as broken.
Consider also that well-written apps that operate here without
problems, may result in problems wen these apps are deleted rather
than properly uninstalled.
It's unusual to find something here, but when you do, it's likely you
would not have been able to find it any other way. The more general
integration checkers such as MSConfig, HiJackThis etc. don't cover
this territory, so I'd not be surprised to see increasing malware use.
"Unusual" isn't "Never". I can remember at least three issues that I
identified and resolved using Shell Extension Viewer.
Finally, compare keyboard with mouse mileage; if limited to mouse
only, consider "special" or "extra feature" mouse drivers, and also
similar things from the graphics driver side of the fence.
I know that's not intuitive, but mouse and graphics are intimately
connected and graphics issues sometimes affect mouse alone.
Good advice, if all you care about is whether Windows runs or not -
and after all. that's MS's only obligation here. Beware of
vendor-vision; I would never follow destructive advice like that.
No, not really - bad exits corrupt files that are in use at the time,
and files specific to that user account are right in the firing line.
If ChkDsk and AutoChk didn't suck so badly, you'd be able to easily
review their logs to see what files they "fixed" (as these automatic
"fixes" usually corrupt the files while masking them from future
ChkDsk scans by destroying the "this file is bad" cues).
Also, look at your av's logs to see if the av cleaned an intrafile
code infector from some relevant code files. Doing so may kill the
virus but leave the cleaned file damaged in ways that can be quite
subtle, depending on what infected it and how.
It should do - it's a nice thourough treatment of the topic
Saws are too hard to use.
Be easier to use!