Windows Update зависає: виправити без очищення ПК

Що означає «зависло» насправді (і чому це не завжди Windows Update)

Коли люди кажуть, що Windows Update «завис», вони зазвичай мають на увазі один із таких сценаріїв невдач:

• Інтерфейс завис: у додатку Налаштування показано заморожений відсоток, але завантаження або встановлення йде у фоні.
• Труба завантаження зависла: машина не може отримати метадані або вміст (проксі, DNS, перехоплення TLS, дивна поведінка Delivery Optimization або пошкоджений кеш).
• Стек обслуговування завис: CBS (Component-Based Servicing) не може застосувати пакети через пошкодження компонентного сховища, відсутні джерельні файли або невідповідний стек обслуговування.
• Фаза перезавантаження зависла: оновлення підготовлені, але під час перезавантаження відбувається помилка й відкат у циклі.
• Обмеження диска/IO: оновлення «зависає», бо сховище повільне, диск заповнений або система треше через деградований диск.
• Вплив стороннього ПЗ: захист кінцевої точки, фільтри диска, «оптимізатори системи» або агресивні утиліти очищення блокують оновлення або видаляють потрібні стани.

Виправлення залежить від того, в якій саме категорії ви знаходитеся. Тому ми не починаємо з бездумного видалення папок. Ми починаємо з вимірювання.

Цитата, яку варто приклеїти на стікер:

«Сподівання — це не стратегія.» — перефразована ідея, яку часто використовують у операціях та надійності

І ще невеликий жарт, бо ви цього заслуговуєте: відсотки прогресу Windows Update схожі на кнопки в ліфті — натискати їх сильніше не зробить поїздку швидшою.

Швидка діагностика (перші/другі/треті перевірки)

Перше: чи дійсно йде робота, чи просто зависло?

1. Перевірте активність диска та CPU у Диспетчері завдань (подробиці). Якщо TiWorker.exe, TrustedInstaller.exe або svchost.exe (wuauserv) завантажені і диск активний, можливо, це повільна, але прогресуюча фаза.
2. Перевірте вільне місце на диску. Якщо системний диск має менше ~10–15 ГБ вільного, оновлення часто зависають або завершуються з помилкою на півдорозі.
3. Перевірте, чи ви зависли до перезавантаження або в циклі завантаження. Якщо «Працюємо над оновленнями» під час завантаження — це інша гілка, ніж «Завантаження 0%» у Налаштуваннях.

Друге: визначте категорію вузького місця

1. Мережевий шлях: DNS/проксі/перехоплення TLS? У корпоративних мережах це часта причина. У домашніх умовах зазвичай це DNS провайдера, VPN або поганий кеш.
2. Стан служб Windows Update: чи працюють потрібні служби, чи вони зависли, чи вимкнені?
3. Цілісність компонентного сховища: якщо DISM/SFC сигналізують про помилки, не варто звинувачувати лише інтерфейс оновлень.
4. Здоров’я сховища: повільні або дефектні диски створюють симптоми «зависання», які не мають прямого відношення до оновлення.

Третє: застосуйте найменш руйнівне виправлення, яке відповідає категорії

1. Безпечні скидання: перезапустіть служби, очистіть SoftwareDistribution та catroot2 (правильним способом), спробуйте ще раз.
2. Відновлення обслуговування: DISM RestoreHealth, потім SFC, потім повторна спроба оновлення.
3. Цілеспрямоване підвищення: аналіз логів, ізоляція конкретного KB, ручна установка з каталогу оновлень або виконання in-place repair install (також не означає очищення даних).

Цікаві факти та історичний контекст (коротко і по справі)

• Обслуговування Windows старіше за «Windows Update»: модель Component-Based Servicing (CBS) походить ще з епохи Vista і досі лежить в основі сучасного обслуговування.
• Папка WinSxS — це не «помилка дублювання файлів»: це компонентне сховище, яке дозволяє зберігати різні версії, обслуговувати та робити відкот — за рахунок складності і використання диску.
• Delivery Optimization (DO) змінила правила гри: Windows може отримувати оновлення від підів на локальній мережі (або Інтернеті залежно від політики), що зручно, поки політика або кеш не пошкоджені.
• Оновлення стеку обслуговування (SSU) існують, бо оновлювач оновлюється сам: якщо стек обслуговування застарів, він може не змогти встановити нові пакети коректно.
• Кумулятивні оновлення зменшили «плутанину Patch Tuesday»: менш окремих патчів, але один некоректний кумулятивний може заблокувати багато всього одразу.
• Windows Update використовує кілька кешів: не лише SoftwareDistribution; також задіяні криптографічні каталоги та стан BITS.
• WindowsUpdate.log колись був простим: у сучасних версіях Windows генеруються ETL-траси, які ви конвертуєте в читабельний лог — корисно для інженерів і дратівливо для всіх інших.
• Деякі збої оновлень — це насправді збої файлової системи/драйверів: фільтр-драйвери (антивірус, шифрування, DLP) можуть спричинити помилки транзакцій, які виглядають як «зависання оновлення».
• Відкат — це функція з таймером: система зберігає дані для відкату протягом обмеженого часу (залежить від версії/налаштувань), що впливає на тиск на диск і можливості відновлення.

Практичні завдання: команди, очікуваний результат та рішення (12+)

Усі наведені нижче команди передбачають виконання з підвищеними правами. Якщо ви на Windows, запустіть «Windows Terminal (Admin)» або «Command Prompt (Admin)». Надписи у блоках коду декоративні; команди — справжні Windows-команди.

Завдання 1: Підтвердити, що служби, пов’язані з оновленнями, не вимкнені або не зависли

cr0x@server:~$ sc query wuauserv
SERVICE_NAME: wuauserv
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Що це означає: STATE: RUNNING — добре. Якщо воно STOPPED, це нормально, якщо оновлень немає; якщо служба вимкнена або не вдається запустити — це проблема.

Рішення: Якщо wuauserv не працює під час спроби оновлення, запустіть її (Завдання 2) і перевірте залежності (BITS, cryptsvc).

Завдання 2: Запустити основні служби (Windows Update, BITS, Crypto)

cr0x@server:~$ net start wuauserv
The Windows Update service was started successfully.

cr0x@server:~$ net start bits
The Background Intelligent Transfer Service service was started successfully.

cr0x@server:~$ net start cryptsvc
The Cryptographic Services service was started successfully.

Що це означає: Якщо якась служба не запускається, текст помилки важливий. «Access is denied» натякає на політики або зламані дозволи; «dependency service failed» вказує на наступну ланку в ланцюгу.

Рішення: Якщо служби не запускаються, не видаляйте кеші поспіхом; спочатку діагностуйте конфігурацію служби, дозволи або корупцію.

Завдання 3: Перевірити вільне місце на диску (нудний вбивця)

cr0x@server:~$ fsutil volume diskfree c:
Total # of free bytes        :  4294967296
Total # of bytes             : 255852544000
Total # of avail free bytes  :  4294967296

Що це означає: Тут у вас ~4 ГБ вільного простору. Це не «трохи», це «лотерея оновлень». Функціональні оновлення та кумулятивні оновлення можуть потребувати кілька гігабайт для підготовки, відкату та тимчасового розпакування.

Рішення: Якщо у вас менше ~10–15 ГБ вільного, зупиніться і звільніть місце перед будь-якими діями. Очищення кешів без вільного простору створює нові режими відмов.

Завдання 4: Швидка перевірка здоров’я системного диска

cr0x@server:~$ chkdsk c: /scan
The type of the file system is NTFS.
Volume label is OS.

Stage 1: Examining basic file system structure ...
  512000 file records processed.
File verification completed.
Windows has scanned the file system and found no problems.
No further action is required.

Що це означає: Якщо воно повідомляє про проблеми, виправте файлову систему перед тим, як звинувачувати компоненти оновлення. Пошкоджена метадані можуть зламати підготовку пакетів і відкат.

Рішення: Якщо знайдено помилки, заплануйте офлайн-ремонт: chkdsk c: /f (може вимагати перезавантаження).

Завдання 5: Перевірити клієнт Windows Update на очевидні стани помилок

cr0x@server:~$ usoclient StartScan

Що це означає: Це запускає сканування. Воно мало що друкує. Мета — викликати активність у логах, які ви можете проінспектувати.

Рішення: Якщо інтерфейс завис, але сканування генерує нові записи в логах, ви у категорії «інтерфейс завис»; переходьте до завдань з інспекції логів.

Завдання 6: Отримати читабельний лог Windows Update (сучасні версії Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsUpdateLog -LogPath $env:TEMP\WindowsUpdate.log"
WindowsUpdate.log written to C:\Users\Administrator\AppData\Local\Temp\WindowsUpdate.log

Що це означає: Тепер у вас є злитий лог, який можна відкрити в Блокноті. Шукайте повторювані помилки, HTTP-коди, проблеми проксі або «FATAL».

Рішення: Якщо бачите HTTP 401/407/0x8024402c — вважайте це мережевою/проксі/ DNS проблемою. Якщо бачите помилки CBS/пакетів — переходьте до DISM/SFC.

Завдання 7: Перевірити чергу BITS (труба завантаження)

cr0x@server:~$ bitsadmin /list /allusers
BITSADMIN version 3.0
BITS administration utility.
(c) Copyright 2000-2003 Microsoft Corp.

{E3C8D2B4-0D3E-4D3D-9C5C-2AABF5C1A7E1} 'WU Client Download' SUSPENDED 0 / 1 0 / 52428800

Що це означає: Призупинена задача може бути нормальною, якщо мережа обмежена або задача поставлена на паузу через політику. Також це може вказувати на завислу чергу.

Рішення: Якщо задачі зависають назавжди, перезапустіть BITS і обережно очистіть проблемні задачі. У більшості випадків скидання компонентів оновлень (Завдання 10/11) чистіше, ніж ручне видалення задач BITS.

Завдання 8: Перевірити конфігурацію WinHTTP proxy (корпоративний винуватець)

cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:

    Proxy Server(s) :  proxy.corp.local:8080
    Bypass List     :  (none)

Що це означає: WinHTTP proxy використовують системні служби (включно з компонентами оновлення), навіть якщо проксі браузера користувача інший.

Рішення: Якщо ви не в мережі або проксі неправильний, скиньте його: netsh winhttp reset proxy. Якщо ви в корпоративній мережі, переконайтеся, що це відповідає політиці організації.

Завдання 9: Підтвердити, що системний час не брешe (TLS і перевірка підписів)

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 2/5/2026 9:12:32 AM
Source: time.windows.com

Що це означає: Якщо час сильно неправильний, перевірка сертифікатів не працює і завантаження/підписи оновлень можуть ламатися неочевидним способом.

Рішення: Якщо остання синхронізація стара або джерело — «Local CMOS Clock», виправте синхронізацію часу перед тим, як шукати привидів оновлень.

Завдання 10: Зупинити служби перед операціями з кешем

cr0x@server:~$ net stop wuauserv
The Windows Update service was stopped successfully.

cr0x@server:~$ net stop bits
The Background Intelligent Transfer Service service was stopped successfully.

cr0x@server:~$ net stop cryptsvc
The Cryptographic Services service was stopped successfully.

Що це означає: Ви не можете безпечно змінювати кеш оновлень, поки служби записують у нього.

Рішення: Якщо якась служба відмовляється зупинитися, перевірте наявність очікуваного перезавантаження або завислої служби; перезавантажте один раз (не п’ять) і спробуйте знову.

Завдання 11: Скинути кеші оновлень (класика, зроблена правильно)

cr0x@server:~$ ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
cr0x@server:~$ ren C:\Windows\System32\catroot2 catroot2.old

Що це означає: Перейменування безпечніше за видалення. Якщо це вирішить проблему, пізніше ви можете видалити папки з розширенням .old, щоб звільнити місце.

Рішення: Якщо перейменування не вдається з помилкою «in use», ви не зупинили потрібні служби — або якесь ПЗ (засіб безпеки, фільтр) тримає дескриптори. Діагностуйте, перш ніж форсувати видалення.

Завдання 12: Запустіть служби та повторіть сканування

cr0x@server:~$ net start cryptsvc
The Cryptographic Services service was started successfully.

cr0x@server:~$ net start bits
The Background Intelligent Transfer Service service was started successfully.

cr0x@server:~$ net start wuauserv
The Windows Update service was started successfully.

cr0x@server:~$ usoclient StartScan

Що це означає: Це змушує відбудувати кеші та метадані.

Рішення: Якщо оновлення починають рухатись за межі 0%/завислих станів — ви були в зоні пошкодженого кешу. Якщо ні — переходьте до перевірки здоров’я обслуговування.

Завдання 13: Перевірити стан компонентного сховища (DISM)

cr0x@server:~$ DISM /Online /Cleanup-Image /CheckHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

No component store corruption detected.
The operation completed successfully.

Що це означає: Якщо повідомляє про виявлену корупцію, вам потрібен /RestoreHealth.

Рішення: Якщо виявлено корупцію — відновіть її перед повторною спробою оновлень. Windows Update залежить від цілісності CBS.

Завдання 14: Відновити компонентне сховище (DISM RestoreHealth)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Що це означає: DISM відремонтував компонентне сховище, використовуючи Windows Update або локальні джерела.

Рішення: Якщо DISM дає помилку джерела (поширені 0x800f081f), можливо, потрібно вказати змонтований ISO як джерело. Не чистіть систему — дайте DISM правильні файли.

Завдання 15: Відновити системні файли (SFC)

cr0x@server:~$ sfc /scannow
Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection found corrupt files and successfully repaired them.

Що це означає: SFC відновив системні файли. Якщо воно не може виправити деякі файли, доведеться переглянути C:\Windows\Logs\CBS\CBS.log і, можливо, повторити DISM.

Рішення: Якщо SFC відновив файли — перезавантажте і спробуйте оновлення ще раз. Якщо SFC не зміг виправити — розглядайте більш глибоку проблему обслуговування.

Завдання 16: Перевірити стан «очікує перезавантаження» (тихий блокувальник)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
ERROR: The system was unable to find the specified registry key or value.

Що це означає: Відсутність ключа зазвичай означає, що прапор CBS «очікує перезавантаження» відсутній. Якщо він є — ймовірно потрібне перезавантаження, щоб завершити попередню інсталяцію/деінсталяцію.

Рішення: Якщо відзначено очікування перезавантаження — перезавантажте один раз, потім спробуйте оновлення. Не робіть 12 перезавантажень поспіль і називайте це планом.

Завдання 17: Швидко переглянути історію оновлень (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5"
Source        Description      HotFixID  InstalledBy          InstalledOn
------        -----------      -------  -----------          -----------
COMPUTERNAME  Update           KB5034123 NT AUTHORITY\SYSTEM 1/30/2026
COMPUTERNAME  Security Update  KB5033375 NT AUTHORITY\SYSTEM 1/15/2026
COMPUTERNAME  Update           KB5032007 NT AUTHORITY\SYSTEM 12/20/2025
COMPUTERNAME  Update           KB5029920 NT AUTHORITY\SYSTEM 11/18/2025
COMPUTERNAME  Update           KB5028851 NT AUTHORITY\SYSTEM 10/22/2025

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

Рішення: Якщо останнє оновлення дуже давнє — віддайте пріоритет перевірці політик/проксі/WSUS (Завдання 18) та здоров’ю обслуговування.

Завдання 18: Перевірити, чи WSUS/політика спрямовує на недоступний сервер

cr0x@server:~$ reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    WUServer    REG_SZ    http://wsus.corp.local:8530

Що це означає: Ця машина налаштована використовувати WSUS. Якщо ви не в тій мережі — ви намагаєтесь купувати продукти в магазині, якого не існує.

Рішення: У керованих середовищах не змінюйте політику без узгодження. На незадоволених машинах видалення політики WSUS може відновити прямі оновлення, але робіть це усвідомлено (і краще після збереження стану політик).

Другий короткий жарт, і потім повертаємося до роботи: Видалення C:\Windows також «виправить» Windows Update, але так само, як видалення двигуна вирішує проблему течі оливи.

Контрольні списки / покроковий план (безпечний, потім хірургічний)

Фаза 0: Не погіршуйте ситуацію (5 хвилин)

1. Підключіть живлення (ноутбуки). Збої оновлень через відключення батареї — самостійно створена проблема.
2. Від’єднайте непотрібні USB-накопичувачі (особливо нестабільні зовнішні диски).
3. Призупиніть інтенсивні IO-задачі: ігри з завантаженнями, синхронізацію хмари, активність VM. Оновлення конкурують за диск.
4. Зробіть швидкий знімок реальності: зафіксуйте стан зависання (0%, 100%, цикл перезавантажень) і будь-який код помилки.

Фаза 1: Швидкі перевірки (15–30 хвилин)

1. Звільніть місце на диску до принаймні 15–20 ГБ на C:, якщо можливо (видаліть великі програми, очистіть Downloads, тимчасові файли). Не використовуйте сумнівні «чистильники реєстру».
2. Перезавантажте один раз. Один чистий перезапуск прибирає багато очікуваних транзакцій і блокувань служб.
3. Перевірте служби (Завдання 1/2). Переконайтеся, що BITS, cryptsvc, wuauserv працюють.
4. Перевірте проксі/час (Завдання 8/9). Якщо час або проксі неправильні — інше все марно.

Фаза 2: Безпечне скидання компонентів оновлень (20 хвилин)

1. Зупиніть служби (Завдання 10).
2. Перейменуйте кеші (Завдання 11): SoftwareDistribution і catroot2.
3. Запустіть служби (Завдання 12) і викличте сканування.
4. Спостерігайте поведінку: якщо завантаження почали рухатися — ймовірно, проблема вирішена. Дайте процесу працювати; не переривайте просто так.

Фаза 3: Відновлення здоров’я обслуговування (30–90 хвилин)

1. DISM CheckHealth, потім RestoreHealth (Завдання 13/14).
2. SFC /scannow (Завдання 15).
3. Перезавантаження.
4. Повторна спроба оновлень.

Фаза 4: Коли DISM потребує джерела (ще не очищення)

Якщо DISM не знаходить джерельні файли, використайте ISO Windows, що відповідає вашій збірці. Змонтуйте його (подвійний клік), потім вкажіть DISM на install.wim або install.esd.

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Що це означає: Ви відновили використовуючи локальне джерело замість Windows Update.

Рішення: Якщо це успішно, запустіть SFC ще раз і повторіть оновлення. Якщо не вдається — можлива невідповідність образу ОС або проблеми на рівні диска.

Фаза 5: In-place repair install (ядерний варіант, але не очищення)

Якщо ви відновили компонентне сховище, скинули кеші, перевірили здоров’я диска, і оновлення все ще відмовляються — in-place repair install може замінити файли системи Windows, зберігши програми та дані. Це фактично «перезастеляє труби ОС», не зносячи будинок.

Правило: Робіть це тільки після збору логів і впевненості в здоров’ї сховища. Ремонт на деградованому SSD — це шлях від «надокучливого» до «втрати даних».

Поширені помилки: симптом → причина → виправлення

1) «Зависло на 0% під час завантаження»

Симптом: Завантаження ніколи не починається; мережевий трафік відсутній; повторні спроби нічого не дають.

Ймовірна причина: Неправильна конфігурація WinHTTP proxy, проблеми з DNS, перехоплення TLS або завислий BITS.

Виправлення: Перевірте проксі (Завдання 8), час (Завдання 9), BITS (Завдання 7). Скиньте компоненти оновлення (Завдання 10–11), якщо кеш пошкоджений.

2) «Зависло на 100% встановлення» (в Налаштуваннях)

Симптом: Інтерфейс показує 100%, але нічого не відбувається годинами.

Ймовірна причина: Йде обслуговування (повільний диск) або CBS застряг у транзакції.

Виправлення: Перевірте активність диска; переконайтесь у достатньому вільному місці (Завдання 3). Якщо дійсно нічого не рухається — відновіть обслуговування (Завдання 13–15).

3) Нескінченний цикл перезавантажень після оновлень

Симптом: «Працюємо над оновленнями» → перезавантаження; інколи «Не вдалося завершити оновлення.»

Ймовірна причина: Конкретний драйвер або фільтр-драйвер ламається під час офлайн-фази; помилки файлової системи; брак простору для відкату; зламаний стан пакету оновлення.

Виправлення: Завантажтесь у Додаткові параметри запуску, використайте Безпечний режим при потребі, виконайте chkdsk і DISM/SFC. Видаліть нещодавно додане ПЗ безпеки/драйвери, якщо є кореляція. Скиньте кеші оновлень, коли система стане стабільною.

4) Помилка 0x800f081f (або «не виявлено джерельних файлів»)

Симптом: DISM не вдається; оновлення можуть відмовляти; SFC не може відновити.

Ймовірна причина: Корупція компонентного сховища плюс відсутність можливості завантажити джерела (WSUS помилково налаштований, машина офлайн або відсутні джерела для опціональних функцій).

Виправлення: Використайте відповідний ISO як джерело для DISM (Фаза 4) або виправте WSUS/проксі політики (Завдання 18 + узгодження з корпоративною політикою).

5) «Служба Windows Update відсутня/вимкнена» після використання «debloater»

Симптом: Оновлення ніколи не запускаються; служби вимкнені; помилки про відмову в доступі.

Ймовірна причина: Скрипт вимкнув служби, змінив дозволи або видалив заплановані завдання.

Виправлення: Увімкніть служби, відновіть дозволи (часто найпростіше через in-place repair install) і припиніть використовувати «тюнінгові» скрипти на машинах, яким ви довіряєте.

6) Завантаження оновлення відбувається, але встановлення постійно не вдається

Симптом: Повторні спроби встановлення, та сама KB не вдається.

Ймовірна причина: Проблеми з компонентним сховищем, конфлікти драйверів або стороннє ПЗ безпеки, що перехоплює файлові операції.

Виправлення: DISM/SFC; тимчасово вимкніть/видаліть сторонній антивірус (якщо політика дозволяє), потім спробуйте знову. Якщо конкретна KB — винуватець, встановіть її вручну або блокуйте до появи кумулятивного виправлення.

Три корпоративні історії з практики

Міні-історія 1: Інцидент через хибне припущення

Вони припустили, що проблема оновлень — «просто інтернет». У нотатках служби підтримки було: ноутбуки віддалені, у користувачів домашній Wi‑Fi, і Windows Update зависав на 0%. Тож перша реакція була передбачувана: сказати всім перезавантажити роутер, вимкнути VPN і спробувати знову.

Це не допомогло. Протягом тижня. Відсоток зависав стабільно, а коди помилок були надто загальними, щоб щось підказати без перегляду потрібних логів. Інженер нарешті перевірив netsh winhttp show proxy на одному з постраждалих пристроїв. Сюрприз: у WinHTTP був вказаний корпоративний проксі, який примусово використовувався системними службами, але ноутбуки були поза мережею. Трафік браузера працював, бо браузер використовував проксі на рівні користувача; Windows Update використовував системний проксі і намагався звернутись до внутрішнього імені хоста, яке не резольвилося у домашніх мережах.

Хибне припущення було тонким: «Якщо веб працює, то Windows Update має доступ до мережі». У корпоративних середовищах це не завжди правда. Системні служби і браузери можуть йти різними мережевими шляхами та політиками.

Виправлення було простим і нудним: коли пристрої поза мережею, або забезпечте доступ до проксі (через VPN), або скиньте WinHTTP proxy на пряме з’єднання. Після цього потрібно було скинути SoftwareDistribution на частині машин, бо невдалі спроби лишили застарілий стан.

Урок полягав не в проксі. Він полягав у повазі до розмежування між мережевими налаштуваннями користувача і системи. Windows Update живе в системному світі.

Міні-історія 2: Оптимізація, яка дала збій

Команда інженерів робочих станцій намагалася «прискорити патчинг», сильно покладаючись на peer-to-peer Delivery Optimization у межах офісних поверхів. На папері це виглядало круто: менше повторних завантажень з Інтернету, швидше розповсюдження і менше трафіку WAN.

На практиці в офісах був мікс комутаторів і VLAN, де multicast був неактуальний, а виявлення пір і broadcast — непослідовні. Деякі підмережі мали агресивну ізоляцію клієнтів, деякі — файрволи з невідповідними правилами, а деякі ноутбуки спали частіше, ніж були доступні.

Результат: група машин намагалася отримати payload оновлення від пір, які були технічно «доступні» у графі DO, але фактично недосяжні або надто повільні. Завантаження починалися, зависали й стояли в стані «suspended». Служба підтримки бачила «зависло на 2%» і звинувачувала Microsoft. Мережа звинувачувала десктопи. Десктопи звинувачували мережу. Ви знаєте цей танець.

Коли тимчасово відключили peer caching для проблемних сегментів — примусово змусивши клієнтів тягнути з офіційного джерела — проблема зникла. Потім DO знову ввели з жорсткішою сегментацією і адекватнішими політиками, після того як реально промапили мережу замість довіряти дефолтним налаштуванням.

Оптимізації — це чудово. Передчасна оптимізація в розподілених системах без інструментів — це спосіб отримати чергу інцидентів, яка ніколи не спить.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінансовий відділ мав набір прикладних програм на Windows, які патчились за чітким графіком. Нічого гламурного: щомісячні вікна обслуговування, кілька етапів впровадження (пілотна група спочатку) і чистий інвентар вільного місця та метрик здоров’я диска.

Одного місяця кумулятивне оновлення почало відмовляти на підмножині машин з помилками встановлення і довгим часом «встановлення». Завдяки базовій телеметрії вони миттєво помітили, що постраждалі машини мали одну нудну спільну рису: на системних дисках було менше 8 ГБ вільного. Це не була таємниця; це була арифметика.

Вони не ганялися за реєстровими правками. Не запускали випадкові «фіксери Windows Update». Вони звільнили місце стандартними засобами очищення, видалили кешовані інсталяційні пакети старого деплоймент-інструменту і розширили кілька розділів, де дозволяло обладнання.

Після цього те саме оновлення встановилось чисто. Без in-place repair. Без перевстановлення образу. Без вихідних вихідних вихідних вихідних вихідних.

Практика не була магічною командою; це була підтримка нудної гігієни: бюджет місця, поетапний rollout і дисципліна вимірювати перед діями. У продуктивних системах нудне — це функція.

Поширені запитання

1) Чи безпечно видаляти або перейменовувати папку SoftwareDistribution?

Так, якщо ви спочатку зупините служби оновлень. Перейменування на SoftwareDistribution.old безпечніше за видалення, бо дозволяє повернути старий стан для аналізу.

2) А що з catroot2 — чому це важливо?

catroot2 зберігає криптографічні каталоги, що використовуються для перевірки підписів. Якщо він пошкоджений, інсталяції можуть падати так, що це виглядає як «зависання завантаження» або «зависання встановлення». Перейменовуйте його після зупинки cryptsvc.

3) DISM RestoreHealth зупинився на 62% (або на якомусь іншому відсотку). Чи це заморожено?

Часто воно працює. Прогрес DISM нелінійний і може призупинятись під час обробки великих маніфестів. Якщо диск активний і процес використовує CPU — зачекайте. Якщо годинами немає IO і CPU — тоді дослідіть (здоров’я диска, журнали подій, доступність джерела).

4) SFC каже, що знайшов пошкоджені файли, але не зміг виправити деякі. Що далі?

Запустіть DISM /RestoreHealth спочатку, потім знову SFC. Якщо і після цього SFC не може відновити, перегляньте C:\Windows\Logs\CBS\CBS.log для конкретних файлів і розгляньте in-place repair install.

5) Чому Windows Update каже 100%, але ніколи не завершує?

Бо «завантажено» і «встановлено» — це не те саме, що «зафіксовано». Оновлення готують payload, потім застосовують зміни через CBS і іноді під час перезавантаження. Повільні диски, брак місця або проблеми компонентного сховища можуть затягнути фінальну фіксацію або спричинити її невдачу.

6) Чи слід використовувати сторонні «інструменти виправлення Windows Update»?

Зазвичай ні. Багато з них — це оболонки поверх тих самих скидань, які ви зробите самі, плюс додаткові «очищення», що можуть зламати обслуговування або політики. У підприємствах вони також можуть порушити базову конфігурацію.

7) Я на корпоративному ПК. Чи можу я скинути налаштування WSUS, щоб виправити проблему?

Не без координації. Якщо політика вказує на WSUS, на те є причина (вимоги відповідності, тестування, пропускна здатність). Правильний крок — переконатися, що ви можете достукатися до WSUS (через VPN) або домовитися з IT про зміну політики для віддалених випадків.

8) Чи схожий дефектний SSD на «зависання Windows Update»?

Так. Оновлення виконують багато читань/записів і перевірок цілісності. Диск з перерозподіленими секторами, тривалими таймаутами IO або помилками файлової системи може спричиняти зависання інсталяцій або відкат. Завжди виключайте проблеми з диском, коли симптоми дивні і повільні.

9) Чи можу я вирішити це, не втративши файли?

У майже всіх випадках — так. Головний «великий молот» — in-place repair install, який зберігає програми і дані. Очищення/скидання робиться, тільки коли ОС занадто пошкоджена або сховище ненадійне.

10) Чому оновлення інколи відмовляють після «debloat» скриптів?

Тому що багато скриптів вимикають служби, змінюють дозволи або видаляють компоненти, які потрібні стеку обслуговування. Windows Update тісно пов’язаний з компонентами ОС; ставлення до Windows як до набору змінних частин призводить до потреби відновлення пізніше.

Наступні кроки (як утримати систему в порядку)

1. Після успішного оновлення видаліть перейменовані кеш-папки, якщо місце на диску важливе:
   • C:\Windows\SoftwareDistribution.old
   • C:\Windows\System32\catroot2.old

   Робіть це лише коли впевнені, що оновлення стабільні.

2. Встановіть поріг вільного місця: якщо C: регулярно опускається нижче 15 ГБ вільного, ви знову зіштовхнетеся з цими проблемами.
3. Не «оптимізуйте» служби оновлень шляхом їх відключення. Якщо потрібен контроль — використовуйте належні політики і вікна обслуговування.
4. На корпоративних машинах перевіряйте VPN/proxy політику перед днями патчів. Мережевий шлях Windows Update — не те саме, що шлях вашого браузера.
5. Якщо у вас була корупція компонентного сховища, заплануйте час для розслідування причин (проблеми з диском, різке відключення живлення, агресивні інструменти очищення, фільтр-драйвери). Виправляйте причини, а не лише симптоми.

Якщо ви нічого іншого не зробите: звільніть простір, скиньте кеші оновлень правильно, запустіть DISM RestoreHealth, потім SFC. Ця послідовність вирішує несподівано велику частину «завислих» систем — без радикальної перевстановлення.