4 ms·

I don't know what MS did to the update system in the last year, but every time my system goes to check updates, it runs at 100% on one CPU for hours. Usually af

I don't know what MS did to the update system in the last year, but every time my system goes to check updates, it runs at 100% on one CPU for hours. Usually after waking it from sleep or a cold boot. I've run the "Problem Fixer" utility for Windows Update, deleted the update cache, and all the other recommendations with no success. I end up killing the wuauserv service to free up that CPU. It used to work 100% fine until the Windows 10 nag/forced upgrade debacle started being pushed out.

retox 10y ago
Same here, only in my task manager its listed as a service host process which is pegging one core at 100%. I didn't understand what it was for months until I must have let it finish because I wasn't doing anything CPU intensive and I got a Windows Update message. Funny thing is that after I clicked to see what updates were available, it had to do the whole process again! This is the last version of Windows I will run.
- Silhouette 10y ago
  We've had some similar problems with Windows Update on our Win7 systems in recent months as well. On a many-cored workstation it's an annoyance. On an older laptop with a dual core CPU, it's crippling. Like others posting here, we see the service host process spinning an entire core at around 100%. That keeps the CPU clock speeds and power draw up all the time as a notable side effect. This seems to be a separate issue from problems with Windows Update taking hours to check for and/or apply the updates themselves.
  - wiredfool 10y ago
    Great, looks like I have both problems.
  - barrkel 10y ago
    Glancing at the stack traces with symbol server downloads enabled, it looks like there's a n^2 or potentially even exponential algorithm being run during the checking phase - checks are run both passively and when actively applying. There's something very wrong with the design of the algorithm - it obviously doesn't scale. Bigger, fewer patches may simply be reducing the size of n. IMO a better approach would be to offload the work to MS: upload a list of applied updates and let the cloud do the crunching. Much higher chance of memoizing and reusing work that way too. It's a sign of MS's client oriented culture still sticking around.
- Severian 10y ago
  Yes, its under one of the many svchost processes that Win7 likes to throw up. And indeed, it wasn't until I loaded up Process Hacker to find out exactly what process was gobbling the CPU.
barrkel 10y ago
On my laptops, I usually run "net stop wuauserv" in a loop with a small sleep. If you're not actively choosing to update that day, it will kill battery life, heat up the machine and keep fan whirring for hours. When I actually want to update, I start the update widget manually. Still takes many hours to update, but it's elective and can be run overnight on mains.
wiredfool 10y ago
That generally matches what I'm seeing, except that my laptop dies after 10 minutes of it.

retox 10y ago

Same here, only in my task manager its listed as a service host process which is pegging one core at 100%. I didn't understand what it was for months until I must have let it finish because I wasn't doing anything CPU intensive and I got a Windows Update message. Funny thing is that after I clicked to see what updates were available, it had to do the whole process again! This is the last version of Windows I will run.

Silhouette 10y ago
We've had some similar problems with Windows Update on our Win7 systems in recent months as well. On a many-cored workstation it's an annoyance. On an older laptop with a dual core CPU, it's crippling. Like others posting here, we see the service host process spinning an entire core at around 100%. That keeps the CPU clock speeds and power draw up all the time as a notable side effect. This seems to be a separate issue from problems with Windows Update taking hours to check for and/or apply the updates themselves.
- wiredfool 10y ago
  Great, looks like I have both problems.
- barrkel 10y ago
  Glancing at the stack traces with symbol server downloads enabled, it looks like there's a n^2 or potentially even exponential algorithm being run during the checking phase - checks are run both passively and when actively applying. There's something very wrong with the design of the algorithm - it obviously doesn't scale. Bigger, fewer patches may simply be reducing the size of n. IMO a better approach would be to offload the work to MS: upload a list of applied updates and let the cloud do the crunching. Much higher chance of memoizing and reusing work that way too. It's a sign of MS's client oriented culture still sticking around.
Severian 10y ago
Yes, its under one of the many svchost processes that Win7 likes to throw up. And indeed, it wasn't until I loaded up Process Hacker to find out exactly what process was gobbling the CPU.

barrkel 10y ago

On my laptops, I usually run "net stop wuauserv" in a loop with a small sleep. If you're not actively choosing to update that day, it will kill battery life, heat up the machine and keep fan whirring for hours. When I actually want to update, I start the update widget manually. Still takes many hours to update, but it's elective and can be run overnight on mains.

wiredfool 10y ago

That generally matches what I'm seeing, except that my laptop dies after 10 minutes of it.