Ken1943 wrote:
There is a succession of patches to WU, and
occasionally one of those reduces the wait.
Because of the backward progress observed
for '710, one would have to assume this
is the usual Microsoft "bandaid" fix for
the problem. And not a real fix.
snip

710 ?


Ken1943

I am referring to the log of results presented
by a poster to askwoody.com . The pattern of
delays for Windows Update to start, is similar
to the bug behavior in WinXP days, for
Windows Update. As far as I'm concerned,
it's the same bug.

The start delay for Windows Update,
is reduced in time, any time that
Microsoft modifies the file manifest
and dependencies, so the CPU-bound
loop won't take as long. At one point,
Microsoft "pruned" an Internet Explorer
part of the tree, in an attempt to prevent
wuauserv for considering the history
of Internet Explorer patches for too long.

In the askwoody comments section, if that
poster had noticed that after '324 update,
the thing was fixed permanently, I wouldn't
need to present the evidence. But after the
'710 update, the problem is back. Which suggests
their attempts at a fix are bandaid based,
and not a rewrite of the non-scalable code.

One of the fixes, does fix the excessive RAM
usage. Some users on Windows 7, see up to
2GB of RAM used by the svchost hosting wuauserv.
And one of the patches reduces that to the
20% level, so only 400MB is wasted, and the
user has some RAM to use for ordinary work.
But there is never an admission of facing
the bug squarely, no "we know what the problem
is and we know how to fix it". There is no
evidence they have a better method to
figure it out.

I think they should upload the user's state
information to an Azure instance, and waste
Microsoft cycles on this :-) Rather than
wuauserv spinning for 40 minutes on each
user machine. At least that would get Microsoft
focused on improving the performance.

Paul