I've a family member who was complaining of her laptop running extremely slowly. Her laptop is an
inexpensive HP unit with 4GB RAM. So the first thing I did was goose it with 8 additional gig. But
then I dug a little deeper and found that the hard drive activity was maxing out immediately and staying
pegged for about 10 minutes or so. Between the hard drive activity and the low RAM, no wonder she
felt like she couldn't do anything when she booted up.
I found that a cumulative Windows update from early May keeps getting stuck and not installing. It's a huge
update — like 1GB. Walking through the issue with HP technicians, I monitored several logs in the
Windows Event Viewer during an install attempt and found the root of the problem documented in
CBS.log: the update code gets hashed and compared with a hash value someplace in sxs, and one part
failed the comparison. The log seems to infer that the automagic fix for this is to repair a corruption
in the component store (which is sxs) — that also seems to be the go-to solution for the HP technicians
— but DISM consistently reports there's nothing to repair, and the repair effort always reports nothing found,
nothing fixed.
If there's a hash for these updates someplace in the component store, then that means the value gets put there
somehow. My guess is the store is fine, but either the hash in sxs is bad, OR there's a problem with the
file Windows Update is pulling down. Let's discuss: - In the latter case, if the hash that sxs
is organically bad, the update should fail on ALL clients, not just mom's — and it installed fine
on my laptop. So maybe that value got munched somehow in transmission to mom's laptop.
- In the former case, it's failing to stage one particular packet — not ALL packets. Clearing the WU
download directory and redownloading is having no effect (as is everything else the HP technician is asking
me to do — but I understand s/he's likely following a script).
I think I need to get smarter on the relationship between the component store (sxs) and Windows Update.
In the meantime, I'm going off-script: I've cracked open a copy I made of the CBS.log and started Googling.
I've found a post from Microsoft which includes a series of steps — many of them I've already done as part
of troubleshooting before engaging HP or as part of the HP troubleshooting... some aren't. I figure I
can include the results in my next post to HP Support.
UPDATE:
I thought I had it licked: Critical analysis of CBS.log gave me crucial clues. The part that was failing
was a file that included major, minor, build and revision numbers that seemed to match the Windows OS. Googling
those numbers led me directly to a patch Microsoft had released in April — the KB number for that release
was not among the updates installed on that PC. So my path was to install this missing update, then reattempt
to install the problematic May update. The instal failed, but the message in the Setup log was far more
direct than the Setup log messages I receive for the failed May update attempts. Perhaps that's something.
|