Windows Update не працює і споживає 100% процесора (Win7 SP1) [дублікат]


79

Я спостерігав дивну поведінку з оновленням Windows (Win7 SP1). Процес svchost споживає ціле ядро ​​моєї віртуальної машини (VirtualBox), не роблячи нічого (тобто немає мережевого трафіку і папка C:\Windows\SoftwareDistributionзалишається однакового розміру з однаковою кількістю файлів). Більше того, процес іноді вимагає великої кількості пам'яті (> 1 ГБ). Я також зазначив, що іноді папка SoftwareDistributionзбільшується в розмірі протягом певного часу, і після цього нічого не відбувається, і svchost продовжує споживати ціле ядро.

Я знаю, що проблема пов’язана з оновленням Windows, оскільки я відстежував (використовуючи Монітор ресурсів), яка служба пов'язана з поведінкою, пов'язаною вище.

На зображенні нижче показано, з чим я стикаюся:

введіть тут опис зображення

Наступне зображення показує детальну інформацію про svchost:

введіть тут опис зображення

Якщо я спробую виконати оновлення, нічого не вийде. Оновлення Windows не працює. Дивіться зображення нижче:

введіть тут опис зображення

Я залишив цю машину, намагаючись зробити оновлення протягом 4 годин. Протягом цього часу споживання процесора залишалося високим (як було зазначено вище), і оновлення не встановлено.

Моє запитання таке:

З якої причини оновлення Windows не працює і все ще споживає все ядро ​​мого процесора, не роблячи нічого?

Пов'язані питання:

svchost.exe високе використання пам'яті - wuauserv


Використовуючи WSUS Offline , також можна (в основному) обійти цю проблему.
Даніель Б

2
Я не можу додати відповідь, оскільки сайт вважає, що я маю репутацію <10, ось що працювало для мене на моїй Windows VM. Це, мабуть, специфічно для ВМ. 1) Збільшити ядра з 1 до чогось вищого. 2) Запустіть оновлення 3102810 у верхній відповіді нижче. 3) Запустіть оновлення Windows. Можливо, потрібні деякі перезавантаження ПК між ними. В основному оновлення Windows не працює добре на 1 ядрі.
Євген К

Купа комп’ютерів у моїй робочій мережі постійно має одне ядро, яке споживаються оновленнями Windows, але користувачі цього навіть не помічають. Microsoft повинна підключити всі ці комп’ютери до розподіленої обчислювальної системи та отримати сотні petaFLOPS безкоштовних обчислювальних потужностей.
Андрій

Відповіді:


83

Виправити

Microsoft випустила клієнтське оновлення Windows Update, що є частиною пакету оновлень оновлень липня 2016 року, щоб виправити тривале зависання при скануванні Windows Update .

Це оновлення містить деякі вдосконалення Клієнта оновлення Windows у пакеті оновлень 1 для Windows 7 (SP1). Сюди входить наступне:

  • Оптимізація, яка стосується тривалого часу сканування оновлень, про які повідомляється на деяких комп'ютерах.
  1. Завантажити:

  2. Зупиніть службу оновлення Windows. Це прискорює налаштування оновлень MSU . Це можна зробити з командного рядка або з вікна менеджера служби .

  3. Спробуйте завантажене оновлення та побачите, чи пришвидшує встановлення оновлень.

Щоб мати змогу встановити оновлення, спочатку потрібно встановити оновлення стеку обслуговування квітень 2015 року для оновлення Windows 7 та Windows Server 2008 R2 (знову зупиніть службу WU перед тим, як спробувати встановити MSU).

Завантажити (оновлення стека з квітня 2015 року):

32 біт

64 біт

Обхід 1

Якщо це все ще не допомагає шукати нові оновлення, використовуйте WSUSOffline, щоб отримати всі оновлення.


7
Ні, це не працює. Встановивши оновлення на 64-бітовій версії Win7, wuauserv все ще марно обертається на 100% процесорі, не роблячи абсолютно нічого, як згідно журналу подій та WindowUpdate.log, протягом тривалих періодів часу. * зітхання *
Томалак

Це вирішило для мене проблему. Примітка: Якщо у вас є одноядерний процесор, нічого не заощадить, жодне виправлення не допоможе. Якщо таке старе обладнання просто відключити службу оновлення Windows, ви не можете працювати з системою, яка зайнята весь час, ризик застаріти в таких ситуаціях неминуче. Швидкі комп’ютери також мають проблему, але це залишається непоміченим, оскільки комп'ютер може це впоратися. У двоядерному Celeron (LGA 775) це спрацювало.
Hatoru Hansou

1
Ця відповідь спрацювала на мене! У мого VM було доступно два ядра, але навіть збільшення його до 6 зовсім не допомогло. Встановити це оновлення досить складно, оскільки воно не працює добре, коли оновлення Windows вже робить щось у фоновому режимі. Перезапуск служби Windows Update та негайно встановлення цього оновлення спрацювали чудово!
jlh

1
@jlh ви можете просто зупинити службу WU через services.msc перед встановленням оновлення MSU. Це значно пришвидшує встановлення.
magicandre1981

1
Зв'язаний KB згадує конкретні проблеми, які він виправляє (оновлення до Win10 та оновлення за допомогою SCCM), але не той, про який тут було запропоновано.
Маттіас Вайлер

8

Після одного дня, намагаючись вирішити цю проблему, я створив іншу віртуальну машину, щоб перевірити, чи проблема може повторитися.

На жаль, проблема повторилася! Після цього я розповів про це питання з другом, і він запропонував мені відключити IPv6 мого мережевого інтерфейсу Windows. Я це зробив і спостерігали дві поведінки:

  1. На новій віртуальній машині, коли я відключив IPv6, споживання процесора майже миттєво знизилось, і оновлення Windows працювало як слід.

  2. На іншій віртуальній машині споживання процесора не впало після відключення IPv6. Помітивши, що я перезапустив Windows, і споживання процесора залишилося високим. Однак через 30 хвилин (приблизно) споживання процесора впало, і все працювало як очікувалося.

Обидва Windows були успішно оновлені після відключення IPv6.

Важливо зазначити, що я можу відтворити таку поведінку. Перед відключенням IPv6 у мене є копії моєї віртуальної машини.


Як і наступні дії - чи все ж здається, що це виправлення працює? У мого колеги виникли ті самі проблеми (100% процесора під час оновлень на 2008R2) і спробували вимкнути IPv6. Після внесення змін він перезапустився, а потім через дві години його процесор знову вискочив.
Rion Williams

1
Привіт @RionWilliams, У моєму випадку для обох віртуальних машин (Windows 7 Professional) це рішення працювало як описано. Однак є й інші рішення, дивіться тут будь ласка: superuser.com/questions/821032/…
cantoni

Привіт знову кантоні. Ми намагалися як виправити IPv6, так і декілька згаданих у публікації, яку ви надали безрезультатно. Однак ми помітили, що це, мабуть, лише проблема з віртуальними машинами, які працюють з одним процесором (як якщо ви використовуєте два, використання процесора перевищує 50%), і він націлений лише на машини, де встановлений смак SQL Server. Я все ще розслідую, але це ті речі, які я до цих пір звузив.
Rion Williams

Відключення IPv6 не допомогло.
Павло

3
Ми працювали на серверах WS2012R2 під ESXi та Windows Updates, які споживали 100% ядра необмежено. Відключення IPv6 у властивостях адаптера працювало на нас. Однією з проблем, яка може зачіпати інших людей, є тип залученого віртуального NIC: ESXi хоче використовувати Intel PRO / 1000s за замовчуванням, що спричиняє купу проблем, але документація VMware рекомендує використовувати адаптери VMXNET 3 для WS2012 чи пізніше. Для цього потрібно завантажити драйвери VMXNET3 з пакунків.vmware.com
tools/releases/latest/windows/index.html

5

Щось ще може допомогти засобом усунення несправностей Windows Update - це окрема програма, яка може діагностувати проблеми з оновленням Windows та службою фонової інтелектуальної передачі (BITS).


Відмінний інструмент !! Довелося запустити TWICE, хоча - вперше було виправлено купу речей, за винятком "реєстрація послуги відсутня або пошкоджена". Але, запустив його знову в W-7, і це теж було виправлено!
DaaBoss

На жаль для мене, інструмент усунення несправностей також крутиться назавжди. Він застрягає на "Розв’язуванні проблем", і за словами менеджера завдань, svchost знову насичує одне з моїх ядер.
AshleyZ

1

Для мене це було виправлено KB2889748

Високе використання пам'яті процесом Svchost.exe після встановлення Windows Management Framework 3.0 на комп'ютер під керуванням Windows

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.