C
Cacadril
I too have seen the "Access Denied" message box during a windows
update install of Windows XP Service Pack 3.
The resolution method 1 of http://support.microsoft.com/kb/949377, is
to download the full service pack download package. I am now
downloading a 316MB file! The d/l page says that the windows update is
much smaller, and recommend it if I only want to update a single
computer.
I have already spent two hours doing all this (Ok, this includes some
backup. However, the "preparing to download" stage hung for about 20
minutes), and the full download takes another 15 minutes.
Method 2 is to turn off any antivirus program and rerun the windows
update.It is not recommended, since it leaves the computer vulnerable
during the install.
I guess this is interesting nevertheless since my antivirus is perhaps
not among the most common ones, so perhaps MS has not tested against
it.
I would like to
1) save ("cache") on my computer whatever the windows update
downloads,
2) then disconnect from the network,
3) then run the install,
4) then reenable the network.
I wish Microsoft would implement some easy and obvious improvements to
their update system.
1) When updating a registry key fails, a) put the registry key in
question in the log file, or include it in the error dialog.
I saw that another KB page suggested rerunning the window update with
additional logging enabled, which would mean another two-hour install
just to reproduce the same error, this time with added logging, and
then fixing the registry permissions, and finally run the windows
update a THIRD time. This is insane. Put the logging of the key in the
error handler, so the key path is logged irrespective of the logging
level.
2) Include in the windows update user interface an option to keep a
copy of the download on disk, or possibly offer to keep a cache of the
files only in the event of a failure.
Yes, I can see some problems. In case of failure, perhaps the file was
corrupted and should NOT be cached. So, at the first sight of the
slightest problem with a proposed solution, give up. Go to bed, and
never rise. Or, think a little more, and make sure the files
downloaded are digitally signed before caching them, and make sure the
install procedure offers to check if a newer version of the package is
available - when installing from a cached file or file set.
3) Include a loop in some error handlers that let users fix problems
and continue that is, e.g. the update program should repeat updating
the registry when the user clicks "try again now". (Yes, this is not
as easy to implement, since it requires that some of the functions be
guaranteed to be idempotent. A good programming practice labels
idempotent functions as such, and strives to achieve that kind of
guarantees.)
Microsoft software has had a general culture of not providing relevant
information about errors. I can understand that technical detail is
undesirable in most cases, because most users feel helpless
confronting such messy details. They feel more comfortable with what
to them appear like transient glitches, and they also respond in more
apropriate ways, eg. trying again later.
What about adding a button "techical details" to the error dialogs?
A general approach to providing usefull error messages: Programs with
properly designed and used error handlers should be able to add nodes
to a list of descriptions of what the program was doing, and what
failed, as the error handlers backtrack. In the event that the
outermost level is failing and the program has to give up, this list
of descriptions should be output somewhere. This will provide context
to the error messages. That context is not otherwise available to the
lower-level routines where the mechanics of the failure can be
described (sytem call X(Y) returned error code Z), and the low-level
error is not usually available at the higher-level. The list combines
both. An error handler that decides a failure is not a failure (eg, a
file could not be opened - ok, it just does not exist, so we do not
need to worry about it), clears the list before moving on.
Regards
update install of Windows XP Service Pack 3.
The resolution method 1 of http://support.microsoft.com/kb/949377, is
to download the full service pack download package. I am now
downloading a 316MB file! The d/l page says that the windows update is
much smaller, and recommend it if I only want to update a single
computer.
I have already spent two hours doing all this (Ok, this includes some
backup. However, the "preparing to download" stage hung for about 20
minutes), and the full download takes another 15 minutes.
Method 2 is to turn off any antivirus program and rerun the windows
update.It is not recommended, since it leaves the computer vulnerable
during the install.
I guess this is interesting nevertheless since my antivirus is perhaps
not among the most common ones, so perhaps MS has not tested against
it.
I would like to
1) save ("cache") on my computer whatever the windows update
downloads,
2) then disconnect from the network,
3) then run the install,
4) then reenable the network.
I wish Microsoft would implement some easy and obvious improvements to
their update system.
1) When updating a registry key fails, a) put the registry key in
question in the log file, or include it in the error dialog.
I saw that another KB page suggested rerunning the window update with
additional logging enabled, which would mean another two-hour install
just to reproduce the same error, this time with added logging, and
then fixing the registry permissions, and finally run the windows
update a THIRD time. This is insane. Put the logging of the key in the
error handler, so the key path is logged irrespective of the logging
level.
2) Include in the windows update user interface an option to keep a
copy of the download on disk, or possibly offer to keep a cache of the
files only in the event of a failure.
Yes, I can see some problems. In case of failure, perhaps the file was
corrupted and should NOT be cached. So, at the first sight of the
slightest problem with a proposed solution, give up. Go to bed, and
never rise. Or, think a little more, and make sure the files
downloaded are digitally signed before caching them, and make sure the
install procedure offers to check if a newer version of the package is
available - when installing from a cached file or file set.
3) Include a loop in some error handlers that let users fix problems
and continue that is, e.g. the update program should repeat updating
the registry when the user clicks "try again now". (Yes, this is not
as easy to implement, since it requires that some of the functions be
guaranteed to be idempotent. A good programming practice labels
idempotent functions as such, and strives to achieve that kind of
guarantees.)
Microsoft software has had a general culture of not providing relevant
information about errors. I can understand that technical detail is
undesirable in most cases, because most users feel helpless
confronting such messy details. They feel more comfortable with what
to them appear like transient glitches, and they also respond in more
apropriate ways, eg. trying again later.
What about adding a button "techical details" to the error dialogs?
A general approach to providing usefull error messages: Programs with
properly designed and used error handlers should be able to add nodes
to a list of descriptions of what the program was doing, and what
failed, as the error handlers backtrack. In the event that the
outermost level is failing and the program has to give up, this list
of descriptions should be output somewhere. This will provide context
to the error messages. That context is not otherwise available to the
lower-level routines where the mechanics of the failure can be
described (sytem call X(Y) returned error code Z), and the low-level
error is not usually available at the higher-level. The list combines
both. An error handler that decides a failure is not a failure (eg, a
file could not be opened - ok, it just does not exist, so we do not
need to worry about it), clears the list before moving on.
Regards