I've been doing some testing over the last couple
days, and I can give some datapoints.
Lets break down the Windows Update process.
List Updates ---- Do Downloads --- Do Installs
Most of my work concentrated on "List Updates".
Test materials - Win7 Pro x64 SP1 installed Aug2015
- Stopped applying WU entirely Nov2015,
after '583 came in and I'd unticked it.
- Experiments consisted of manually executed
scans for updates.
List Update timings:
80 minutes - Test materials unmodified. Just let it run.
50 minutes - My best effort to pre-install IE11 cumulative,
MSRT, Windows Defender definitions, all .NET
updates, special '710, '810, '612, '851 WU-related
patches (testing after each one of those0. In
other words, nothing works to materially stop
2.5 minutes - After all remaining 48 security updates and
23 optional updates are installed (even '583),
then retest and find Microsoft offering .NET 4.6.
In other words, there were some pending updates
in the list. And 2.5 minutes is pretty well the
minimum, as TrustedInstaller scans for that interval,
and normally at that point, the protracted "wuauserv"
100% CPU on one core thing, would take over. So, fully
patched, the supersede check takes no time at all.
I did not spend the time examining those items,
to guess which one helped drop the time so much.
Other means of probing Windows Update.
1) WSUSOffline. We know this works pretty well. But it
may have its own supersedence pruning as a script.
2) Microsoft Baseline Security Analyzer 2.3 (MBSA).
It takes a couple minutes to scan and list the
security updates (48 of them). But it doesn't
list the optional update items that WU shows.
So what various manifests have I seen.
1) When you install a Windows Update you download direct
from a MS KB web page, that is a file in ".msu" format.
It has a WSUS cab inside, and inside that is a single
package.xml file. Two Windows 7 updates, had the same
~250KB package.xml file. So the file does not appear to
address just the update itself. And the "wusa.exe"
installs a .msu in a speedy fashion. No complaints.
2) Back in 2008 or so, the file manifest from the catalog
server was around 8MB. It had a handful of package.xml
files, with no discernible pattern of why the files were
split. When WSUSOffline downloads that file in 2016, the
file size is 125MB. And it has many package.xml files in
So the scale of the file manifest has increased dramatically.
And "wusa.exe" only has to deal with a 250KB single file,
while Windows Update could be dealing with some fraction
of that 125MB file. I don't really think I've seen
WU download a 125MB file, so I don't know if WSUSOffline
asks for everything and that is the difference or not.
WSUSOffline has to handle multiple OSes.
In Apr 2016, *all phases* of Windows Update are slow.
80 minutes of wuauserv spinning its wheels.
Wuauserv Private memory usage is moderate. Less than
100MB shows. If the OS is put under memory pressure,
at the same time as wuauserv is in its 100% CPU loop,
the private memory drops to only 9MB of so. Private
memory only increases slightly once the memory pressure
is gone. There's something smelly about this behavior,
because it suggests any "calculation" wuauserv is doing,
doesn't access much memory at all. In other words, the
"bloat" up to 2GB seen in the past, is largely just a waste
Using Process Explorer, drilling into wuauserv and
clicking the Stack button, shows this kind of thing.
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 [ wuauserv using a
ntoskrnl.exe!KeWaitForMutexObject+0x19f mutex, via kernel call ]
So stack sampling while it is in its loop, shows it
using a Mutual Exclusion semaphore of some sort. There's
really nothing wrong with seeing that on the return
stack. When things deadlock, you might expect to see
such a thing. I could find a Python bug and some
sort of Torrent program bug, which were stuck on similar
things on the stack. And there doesn't appear to be
enough other "junk" to make it look like this is
part of a properly operating piece of software. There
aren't a lot of threads.
I expect seeing those ntoskrnl calls, is why someone in
the Answers forum was suggesting the '852 win32k.sys
kernel fix as the "cure" for wuauserv. But when I
tested that here, it did absolutely nothing useful
for me. The time was still 50 minutes.
Someone in one of the WU threads here, suggested that
"maybe Microsoft was throttling downloads". I fired up
a copy of TCPView to watch what goes on.
What I find in Apr.2016, is TrustedInstaller is *still*
thinking about something while the download phase is
supposed to be happening. You would think on the client
end, you have a list of 48 updates, you use BITS to download
all 48, at link speed. What I found, was lengthy delays
on the client end, not opening any connection at all.
When a connection did open, BITS would open anywhere from
6-12 connections and do the download step in parallel. For
one download file of decent size, I didn't see any evidence
The problem appears to be "too much thinking" happening
on the client end. When really, the stupid thing has its
list of downloads, and should just execute them. No thinking
should be required. It already wasted 80 minutes getting
to this point. Why is it still thinking ?
Even the installation process seems slower than ones you
do with wusa.exe (or dism). I don't remember the details
of what I saw, but the disk light did not do a lot of
flashing - the installation process was not disk limited,
not by a long shot.
So "entirely too much thinking" is happening on the client end.
And "not enough doing". Windows Update has become intellectual
in its old age.
So if you see it run for nine hours total, every phase of
the operation is slow. Is it on purpose ? Should the
manifest file from Microsoft be 125MB in size ? Is
that reasonable ? Is it caused by an explosion of
Win10 materials ? Who knows.
It's too bad we couldn't get Mark Russinovich working
on this. I bet he could figure it out :-) Maybe he'll
get pissed one of these days, waiting for a home
machine to finish updates, and get to work on it.
Now that he's been promoted, he probably doesn't
have time for his favorite hobby (sticking a fork
into Microsoft implementations).