Thread: Update errors
View Single Post
  #9  
Old August 23rd 15, 04:57 PM posted to alt.comp.os.windows-8
Paul
external usenet poster
 
Posts: 18,275
Default Update errors What next

Keith Nuttle wrote:
On 8/21/2015 3:36 PM, Keith Nuttle wrote:
I had to reinstall every thing after trying Windows 10. I made it
through the 155+ updates to Windows 8, installed Windows 8.1,and most of
its updates.

The updates and it appears downloads from the Windows store is no longer
working.

I checked and see I am getting repeated occurrence is of this error.

Since I tried repeatedly to install the updates, I thought it could be
the problem. Can some one help'

"The server {4991D34B-80A1-4291-83B6-3328366B9097} did not register with
DCOM within the required timeout."


It has been a week since I had to rollback Windows 10 after it was
locking up the computer to Window 8. As I have said the roll back put
me at the OEM OS and I had to reinstall all of the updates, AND then
install Windows 8.1. Things are still not back to normal

The update system is broken. I have tried everything that has been
posted and and all of the suggestions on the sites provided except
exporting parts of the registery to fix the problem. (I do not have
access to another 64 bit computer.)

Most recently I downloaded WindowsUpdateDiagnostic.diagcab. and ran it.
When I tried the individual option, after over a half an hour they
never completed. On the third try I ran the advance option, and it did
finish but had errors after appearing to down load a couple of files.
(as see in the task manager Disk activity not in the Internet activity )

Right now the update facility is not working and it looks like my only
option is to back up all of my data, use the Toshiba reinstall the OEM
Windows 8 on a cleaned disk and start over. This time as has been
suggested I will use the Install tool to install Windows 8.1.

I guess there is a second option that is to live with a broken computer
and not have Solataire.

Is there any thing else I can do short of the start over option?


Go to the Troubleshooting control panel. Type "Update" in
the search box in the upper right hand corner of Troubleshooting.
That would give the built-in version of diagcab for Windows Update.

The basic recipe for Windows Update is pretty simple. Turn off
two services. Now that nothing owns SoftwareDistribution folder
clean it out and start again. Turn the two services back on.
When Windows Update is run by the user, the SoftwareDistribution
state information will be regenerated.

For a free copy of Solitaire from the MicrosoftStore (versus
porting one from a previous OS), the Windows Store subsystem
has to be working. AFAIK, it shares BITS subsystem with
Windows Update, but I could be wrong. And the tool for
cleaning the cache used by WindowsStore is "wsreset.exe".

"When WSReset.exe runs, it will open the Windows Store app.
The Windows Store app screen will reset a couple times
while the tool is emptying the app's cache and then it's
done. It's a quick process."

Could you have some permissions problems these tools
can't fix ? Quite possible. Microsoft repair tools
don't seem to deal with complicated situations, and
assume a benign rather than a hostile environment.
There's no reason for the tool to consider
a permission could be set wrongly. And no,
smashing everything with TakeOwn, doesn't
solve a problem (necessarily) where
TrustedInstaller is supposed to be
the owner.

Have a look for log files, such as WindowsUpdate.log
or cbs.log. Or even Event Viewer. There is a one-liner
for cleaning out Event Viewer, but of course that
also removes useful history a diagnostician might
need. As hard to believe as that might be (that
anyone could stomach the interface long enough
to spot a problem).

(Event Viewer cleaning recipe, one-liner for powershell)
http://jpwaldin.com/blog/?p=166

(To be run in an Administrator powershell.exe window)

wevtutil el | Foreach-Object {wevtutil cl "$_"}

And because I can't keep all the logs in my head,
I sometimes use Agent Ransack, look for all log
files, and sort them by date. Then, if I've been
messing with a subsystem, the theory is that the
associated log has the latest date stamp. And that's
how I figure out what log might be the one to consult.

HTH,
Paul
Ads