Windows 7 - Windows Update Sucks - Considerations

Asked By Atlas on 14-Feb-07 05:35 AM
I would like to have a reasonable motivation, in architecture terms, about
why Windows Update spikes CPU to 100%.

It is the only software update architecture that sucks CPU (and sucks
itself) in such a manner. There's no other software update that bends the
computer on it's knees, like WU.

Even the fix issued by ms support doesn't solves the problem.

Having said so, at least people would be happy to understand why, ms took
this approach.... nevertheless I still think that the windows update project
manager is a complite idiot and should be fired, if not prosecuted, having
planned such an unusable system.

Yes unusable.

How does Mr-Project-Manager think that. in an organization, daily updates
are scheduled, blocking PC to 100% every day for 10 minutes? Absolutely
impossible.

That's why now we're scheduling manually updates on a weekly basis, letting
the PC's exposed to threaths.

What you other community-users think?




MowGreen [MVP] replied on 14-Feb-07 05:59 PM
The biggest issue is that XP needs *** SERVICE PACK 3 ***
You can rail about WU  to your heart's content, but there is a temp
workaround for what you are witnessing.
And, no, it's not the latest msi.dll, if that's the 'fix' that MS sent
to you. Search this newsgroup and you'll find it.

Because of the push to get Vista out, SP3 for XP was pushed back. When
did SP2 come out ? 3 years after XP was released . And that was a
*major* reworking of XP, it was not just limited to hotfixes, rollups,
and updates.
There have been a considerable amount of updates since SP2 was released.
When a system is scanned at WU or even when Automatic Updates is spawned
by svchost, there is CONSIDERABLE territory to cover. That's what is the
main cause of the CPU spiking to 100%.

It is not the architecture. In fact, MS has done a laudable job with the
updating process. Think of all the possible permutations of hard and
software that exist on PCs worldwide. Now check the Windows Update
newsgroup. What percentage of all PC Users post to the WU newsgroup ?
VERY small compared to the total number of Users.

That does *not* absolve MS from any blame for not getting SP3 out
faster. But, compare the updating process of MS with other software vendors.
Sun is a joke. They leave vulnerable, older versions on the system AND
they attempt to install a Google toolbar/ desktop search with their updates.

Same with Adobe. They try to install the Yahoo toolbar with each new
version of FlashPlayer that is released for SECURITY reasons.

*** How much yowling would there be if MS tried to install the MSN
toolbar with their SECURITY updates ? ***

There are no alternative update methods for Adobe or Sun. MS at leasts
offers Users a choice.
You can just be notified of updates and then obtain them at the MS
Download Center or the Windows Update Catalog. Plus, they offer
different means of said notification.
I don't see other software vendors offering that.

Sorry, I disagree with your conclusion that Windows updating is
unusable. Have only had 2 updates fail to install in 11 years, so MS
must be doing something right.


MowGreen  [MVP 2003-2007]
===============
*-343-*  FDNY
Never Forgotten
===============
Atlas replied on 15-Feb-07 04:45 AM
Mow thanks for getting into the discussion.

I think the problem is down to what approach MS took to update the
installation; why it is so CPU intensive? It would have been reasonable a
disk intensive process (scan all exes, drivers, dlls to check if they need
to be updated), but apart from that why did not ms go for a simple database
approach?
They simply could have stored each program version into it, then let the
update program access the Internet to ms servers and check if any updates,
eventually with a very low priority  & low consuming process. Very simple
and low consuming.




Could you briefly spot out the workaround?
MowGreen [MVP] replied on 15-Feb-07 05:15 PM
You're welcome, Atlas. Windows Update is a never ending education ;)
It's about to change again and, hopefully, be less CPU intensive.



I suspect the high CPU useage is also related to the scan of the *.edb
logs on the system, *all relevant sections of the registry*, and
registered .dlls to determine if a 'product' needs to be updated.
There is a datastor.edb in %windir% that can grow quite a bit. I don't
think it was intended to store more than temporary information while the
scan and updating process takes place. Most likely, I'm wrong.
They are extensible data bases, AFAIK.

I do know that even if one bit of an app or program is detected, then
any relevant updates for it will be offered. Which is why some folks are
offered updates to the MS JavaVirtualMachine even though it is no longer
on the system. Just one bit detected in the registry will trigger the
offering.


Not quite sure I get what you're driving at. Can you expand on the above
please ?


MowGreen  [MVP 2003-2007]
===============
*-343-*  FDNY
Never Forgotten
===============
Atlas replied on 16-Feb-07 11:01 AM
I think that the update process is doing something else, like testing
product genuinity, you name it.....



There's no point in scanning the registry.......

Here's a simple effective idea.

A very simple database holding products installed and for each product, the
updates installed

Product Table -> | Product ID | genuine (yes/no/unchecked) |
1<>N
Update Table ->  |Update ID | Product ID |

* When updating *
(A)  for each product in "Product table"
- load updated records from "Update Table"
- get available updates list from the Internet for "Product ID"
- compare local list (Update ID)  with Internet list (Update ID)

(B)- Show availabale updates, if any

(C)- Do updates if requested (at this point check genuinity)

With a fair Internet connection, step (A) shouldn't take more than 30
seconds, with 0% CPU!!!