Microsoft Windows Vista Community Forums - Vistaheads
Recommended Download



Welcome to the Microsoft Windows Vista Community Forums - Vistaheads, YOUR Largest Resource for Windows Vista related information.

You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so , join our community today!

If you have any problems with the registration process or your account login, please contact us.

Driver Scanner

Keep the Service Pack installation file in case of errors

microsoft.public.windowsupdate






Speedup My PC
Reply
  #1 (permalink)  
Old 06-02-2008
Cacadril
 

Posts: n/a
Keep the Service Pack installation file in case of errors
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
Reply With Quote
Sponsored Links
  #2 (permalink)  
Old 06-02-2008
Shenan Stanley
 

Posts: n/a
Re: Keep the Service Pack installation file in case of errors
Cacadril wrote:
> 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.


Keeping a log, eh?

In any case - my suggestino to you is to do Method 3 only from the article,
reboot and install SP3 - save yourself time.

--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html


Reply With Quote
  #3 (permalink)  
Old 06-03-2008
PA Bear [MS MVP]
 

Posts: n/a
Re: Keep the Service Pack installation file in case of errors
Free unlimited installation and compatibility support is available for
Windows XP, but only for Service Pack 3 (SP3), until 14 Apr-09. Chat and
e-mail support is available only in the United States and Canada.

.. US:
http://support.microsoft.com/oas/def...3&gprid=522131

.. CA:
http://support.microsoft.com/oas/def...3&gprid=522131

.. UK:
http://support.microsoft.com/oas/def...3&gprid=522131

.. AU:
http://support.microsoft.com/oas/def...3&gprid=522131

.. Other: http://support.microsoft.com/oas/def...spx?gprid=1173 | select
Windows XP | select Windows XP Service Pack 3

WinXP-specific newsgroup: microsoft.public.windowsxp.general
--
~Robear Dyer (PA Bear)
MS MVP-IE, Mail, Security, Windows Desktop Experience - since 2002
AumHa VSOP & Admin http://aumha.net
DTS-L http://dts-l.net/

Cacadril wrote:
> 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


Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Service Pack 3 Installation Failure Bolstadnm microsoft.public.windowsupdate 7 05-15-2008 22:08
Service Pack 3 Installation Error Rebel Still microsoft.public.windowsupdate 6 05-10-2008 09:47
Service Pack 2 installation nightmare Tina Maire microsoft.public.windowsupdate 15 02-13-2008 05:41
Installation of Vista Service Pack 1 Alarcin microsoft.public.windows.vista.general 4 02-13-2008 03:02
Re: Service Pack 2 installation issues. RKPreyer microsoft.public.windowsupdate 1 11-30-2007 01:57




All times are GMT +1. The time now is 22:27.




Driver Scanner - Free Scan Now

Vistaheads.com is part of the Heads Network. See also XPHeads.com , Win7Heads.com and Win8Heads.com.


Design by Vjacheslav Trushkin for phpBBStyles.com.
Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.6.0 RC 2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120