Microsoft Windows Update has a track record of having the worst error reporting, usually throwing error codes, rather than helpful errors. I stumbled on another case of this after I worked on 2 identical machines this week. Windows Update reported the unhelpful error code 0x800f0818 during an update of .Net 3.5 SP1.
The scene, a crazy busy week, frantically trying to do the jobs of 5. I had 2 machines to do updates on, and get ready for some software. These machines were identical, they were identical because one was built, then the other was cloned from that machine. We’ll call the machines DALIIS001 and DALIIS002, where DALIIS002 was a clone of DALIIS001. During performing updates on these machines, I hit a stumbling point. DALIIS002 rocketed through the 65 initial updates, and was done in about 45 minutes. DALIIS001 got stuck on 61 of 65. After about an hour stuck on the 1 update, I decided to go to bed1.
When I got up, it was still sitting on 61 or 65, so I clicked cancel, nothing. I shut the machine down, and was promptly kicked from the remote desktop, but I noticed it wasn’t shutting down, so I used vmware console to look at the machine, and saw it had killed my session, but was still trying to install 61/65. So I did the thing the message on the screen said not to, I reset it.
The machine went through 3 reboots, and finally came up. When it tried to re-install that same update, it started throwing the error 0x800f0818. The next round of updates recommended I installed System Update Readiness Tool. A quick look at the notes says it scans the system, and makes sure some stuff is ready for updates, and can fix common issues. I let it run, but it still had the same error.
After poking around a bit, I stumbled upon a blog post by Jason Duffett, titled Windows 2008 R2 Service Pack 1 won’t install!, who seemed to be having a similar issue with with 2008R2 SP1. I had apparently missed something with the System Update Readiness Tool (SURT), and that was to look at the log.
As Jason had observed, SURT was finding corrupt files, but not fixing them. Fortunately I had a clone of the machine I was working on, so I followed Jason’s instructions, copied the necessary files to the broken machine, and re-ran SURT, this time showing no errors. After battling with the corrupt files, I re-ran the Windows Updates, and the .Net service pack installed, as did the Windows service pack.
It would be nice if Microsoft gave out more useful error messages, or at least a little more details to the error instead of forcing us to go digging through the depths of the operating system to find the cause of these mysterious error codes. A big thanks to Jason Duffett for having the solution.
-
This was 23:30 after all. ↩