Jan Il said:
Hi Robert
....
Just to touch on this part here a bit. I have been reminded on many
occasions, both on and off newsgroups, that an IE repair should not be
suggested unless it is the very last resort, and only if certain conditions
or problems are at hand. That is why I have refrained from offering it as a
possible solution until all other avenues have been exhausted. Often, the
OP has spent many hours toiling on their end to no avail, and the Repair is
ultimately the only recourse left to them.
If I understand your statement here, you are saying that responders should
recommend it more often, for less critical problems? This is an area that I
would very much like to clarify, for my own personal information, but, I
think it would also be good for other readers to know this as well.
If you are going to give someone some regsvr32 commands
or a reg hack (especially multiple re-registrations or a reg hack which is
a subset of a re-registration) I think that they might as well be the most
complete ones and users should be told about their options up front
and not kept waiting so we can tactically? keep some stronger repairs
in reserve.
The main objection that I can think of against an IE Repair is the
disruption of the boot that it forces. Otherwise the effect of it is
to do a mass of regsvr32 commands under controlled conditions
at boot time. Except for the boot I suspect that most users would
find this an easier procedure to follow than a bunch of regsvr32
commands. We have seen countless examples where there is
confusion about the syntax (e.g. spaces being ignored, and other typos.)
and other cases where modules mentioned don't exist in the user's OS, etc.
Those problems would be avoided as well with a more conventional GUI
oriented procedure which was specifically tailored to the user's OS.
The main objection that I have about the particular sets of regsvr32
commands which are commonly suggested is that they aren't as complete
as they could be, specifically the /i switch where appropriate, usually
is not given. That issue is moot also with a full repair.
Individual regsvr32 commands and reg hacks seem useful to me
mostly as diagnostics or for their documentation value
but often they are misinterpreted as "solutions".
So another objection to the concept of the IE Repair might be that by doing
all re-registrations at once you may lose the diagnostic value of being able
to do them one at a time. But the only time that I think I would bother with
that approach is if an incident is identified as a recurring problem.
E.g. then you might like to know specifically which module seems to be
associated with the problem cause.
In fact, IIRC that is exactly what happened with KB281679.
When it was first written it mentioned regsvr32 urlmon.dll *only*.
That was intended to be a workaround only for the IEAK problem
which you can still see mentioned there. And I believe it was originally
only written for XP users, which made an IE Repair inapplicable.
Note that it could have mentioned regsvr32 /i urlmon.dll if it was trying
to suggest a broader repair while still providing a simple workaround.
Over time KB281679 was transformed into a more general purpose
repair procedure still without acknowledging the possibility of stronger
alternatives.
XPsp2 with its /rereg switch should have been an even simpler
general purpose "solution". Unfortunately something seems to have
been botched in its implementation. Notice that you can't even find
an official reference to it any more except on non-English versions
of KB870700. Instead they keep falling back with references
to sfc /scannow which I am still to be convinced has anything
to do with module re-registration (i.e., the main purpose of an
IE Repair.)
Thank you very much for your time and help. <g>
FWIW
Robert
---
Jan
MS MVP - IE/OE
Smiles are meant to be shared,
that's why they're so contagious.
