Банер має зверхній тон. Кнопка каже Check for updates. Ви натискаєте. Крутиться. Потім повертається як бумеранг:
«Your device is missing important security and quality fixes.» Знову. І знову. І якось це завжди виглядає ніби ваша провина.
Це не ситуація «вимкніть і ввімкніть знову» — хоча перезавантаження часто буває першим кроком. Це стек Windows Update, який
збитий, заблокований, пошкоджений, пов’язаний політикою або чекає на певну попередню дію, яка ніколи не відбувається. Ми змусимо її відбутися.
What the loop actually means
Це повідомлення не є однією конкретною помилкою. Це загальний сигнал Windows Update «я не можу довести, що ви на потрібному рівні патчів».
Воно з’являється, коли механізм оновлень вважає, що є застосовні оновлення, але не може завершити встановлення — або не може довести, що воно завершене.
Таке відбувається з банальних причин (очікуваний перезавантаження), структурних причин (пошкоджений component store) або політичних причин (WSUS / відкладення /
лімітована мережа / призупинені оновлення). Також це може бути через те, що Windows Update намагається встановити оновлення в неправильному порядку, особливо
якщо ситуація з Servicing Stack Update (SSU) заплутана на старіших збірках.
Правильна ментальна модель: Windows Update — це конвеєр із багатьма рухомими частинами — служби, папки кешу, криптографічний каталог,
локальний component store, політичні вхідні дані й механізм обслуговування (CBS). Банер з’являється, коли конвеєр постійно падає на певному етапі,
часто не повідомляючи вам, на якому саме етапі у GUI.
Ми ставитимемо це як реагування на інцидент у продакшені: ідентифікуємо підсистему, яка не працює, застосуємо найменш ризиковий ремонт і підтвердимо
результат твердими сигналами (логи, стан служб, ідентифікатори подій). Без випадкових «очищувачів реєстру». Без шарлатанських оновлювачів драйверів.
Fast diagnosis playbook (check 1/2/3)
1) Confirm whether you’re blocked by “pending reboot” or servicing locks
Якщо Windows думає, що потрібен перезавантаження, воно охоче продовжуватиме просити оновлень, відмовляючись їх завершити. Це найпоширеніша
причина «петлі» у великих парках.
- Перевірте: індикатори pending reboot у реєстрі та статус Windows Update
- Рішення: перезавантажте один раз (чистий перезавантаження), потім повторно перевірте оновлення перед тим, як робити щось радикальне
2) Check policy and source: Windows Update vs WSUS vs “managed by your organization”
Машина, спрямована на WSUS (або частково спрямована), може застрягти: GUI спілкується з Microsoft Update, але агент змушений
використовувати внутрішній сервер, який неправильно налаштований, позбавлений схвалень або заблокований проксі. Це дає петлі, що виглядають як корупція, але
фактично є «політика винна».
- Перевірте: ключі політик у реєстрі та фрагменти логів WindowsUpdate
- Рішення: або виправте доступність/схвалення WSUS, або тимчасово видаліть політику (якщо вам дозволено)
3) Repair the Windows Update plumbing: services + cache + component store
Якщо служби не працюють, кеш отруєний або component store не здоровий, ви можете скільки завгодно завантажувати оновлення й
ніколи не завершити їх встановлення. Тут ми скидаємо SoftwareDistribution/Catroot2 і запускаємо DISM/SFC.
- Перевірте: стан служб, пошкодження папок, стан DISM
- Рішення: скиньте компоненти WU, потім відремонтуйте component store, потім спробуйте оновлення знову
Interesting facts and short history (because context helps)
- «Quality updates» стали іменованими в Windows 10, коли Microsoft перейшла на накопичувальні щомісячні оновлення замість великої кількості дрібних патчів.
- Servicing Stack Update (SSU) існує тому, що Windows має оновлювати свій механізм оновлення; якщо стек занадто старий, новіші накопичувальні оновлення можуть провалюватись.
- Windows Update мав кілька епох логування: старий WindowsUpdate.log був статичним; новіші збірки генерують його динамічно з ETW трас.
- SoftwareDistribution не є священними даними; це кеш. Пошкоджений кеш спричиняє феєрично повторювані збої.
- Catroot2 відповідає за криптографічні каталоги; якщо підписи й каталоги не верифікуються, інсталяції падають навіть при успішному завантаженні.
- WSUS існував задовго до Windows 10 і був спроєктований для контрольованого корпоративного патчингу — чудово, коли його підтримують; пастка, коли його занедбують.
- Delivery Optimization (DoSvc) ввів розповсюдження оновлень від однієї машини до іншої; це знижує трафік і може створювати дивні ефекти на неправильно налаштованих мережах.
- Windows servicing використовує CBS (Component-Based Servicing); коли CBS хворий, симптоми виглядають як «помилка оновлення», хоча реальна проблема — component store.
- Функції відкладення та паузи змінили режими відмов; машина може «бракувати фіксів», одночасно навмисно утримуючись політикою.
Three corporate mini-stories from the trenches
Mini-story #1: The incident caused by a wrong assumption
Портфель ноутбуків фінансового відділу почав показувати банер про відсутні фікси після квартального оновлення. Helpdesk зробив те, що зазвичай
робить: перезавантаження, запуск troubleshooter, порада користувачам «спробуйте завтра». Через тиждень сканери вразливостей почали сигналити. Керівництво
поцікавилось, чому «патчинг зламався».
Неправильне припущення було простим: «якщо UI Windows Update може перевірити Microsoft, значить машина не в управлінні». Насправді GPO кілька років тому встановив ключі WSUS,
потім хтось пізніше припинив проєкт міграції WSUS на півдорозі. Клієнти були спрямовані на внутрішню
службу оновлень, яка більше не існувала. Вони могли говорити з інтернетом, але агент не хотів ним користуватися.
Рішення не було в DISM. Це була гігієна політик: видалити застарілі WSUS-ключі, примусово зробити gpupdate, перезапустити служби оновлень і перевірити знову.
Оновлення встановились негайно. Банер зник так, ніби його й не було — саме так політичні проблеми люблять глузувати.
Урок: якщо система «керована», ставтесь до неї як до керованої, поки не доведете протилежне. UI — не доказ. Реєстр — доказ.
Mini-story #2: The optimization that backfired
ІТ‑команда намагалася зекономити трафік на невеликому кампусі, сильно покладаючись на Delivery Optimization. Вони агресивно його тонували: більше обміну між пірінгами,
довше зберігання кешу та віра в те, що «мережа витримає». Переважно витримувала — поки не перестала.
Під час Patch Tuesday певна підмножина машин почала петляти з «missing fixes». Завантаження були швидкими, інсталяції падали. Логи показували
проблеми валідації підписів і часом часткові payload-и. Шаблон був підступний: це торкнулося машин із нестабільним Wi‑Fi і тих, що
переміщувались між корпусами.
Вони створили ідеальний шторм: пірінги швидко роздавали контент, але переривчасте з’єднання спричиняло пошкоджені або неповні передачі,
які не перевірялися належним чином перед інсталяцією. Кеш продовжував роздавати ті самі погані байти. Скидання кешів вирішило негайну проблему.
Пом’якшення налаштувань Delivery Optimization вирішило її надовго.
Урок: оптимізації розподілу чудові, поки вони не стають підсилювачем корупції. Якщо ви оптимізуєте доставку, оптимізуйте також валідацію й відновлення при помилках — інакше ви просто пришвидшуєте появу помилок.
Mini-story #3: The boring but correct practice that saved the day
Регульована корпорація мала нудне правило: щомісячні вікна техобслуговування, обов’язковий перезавантаження протягом 24 годин після встановлення патчів
і панель, яка відстежувала стан «pending reboot» окремо від «updates missing».
Одного місяця позачергове оновлення безпеки спричинило більшу кількість банерів «missing fixes». Команда безпеки панікувала.
Операційна команда — ні. Вони подивились на панель: більшість уражених машин були в стані «pending reboot», а не «failed update».
Вони організували примусовий вікно перезавантажень (з комунікацією користувачам і планом відкату). Банер зник на більшості машин без жодних ремонтних робіт.
Менша частина потребувала ремонту component store, що було виконано спокійно, бо початковий шум було усунуто.
Урок: нудна операційна дисципліна знижує помилкові інциденти. Перезавантаження не гламурні, але й пояснювати аудиторам, чому «ми планували перезавантаження наступного тижня», також неприємно.
Practical tasks (commands, outputs, decisions)
Нижче реальні завдання, які ви можете виконати в Windows (PowerShell або CMD). Так, запрошення виглядає як у Linux, бо мені подобаються передбачувані підказки.
Команди й шляхи реальні для Windows. Запускайте від імені Administrator, якщо не вказано інше.
Task 1: Identify Windows version and build (don’t guess)
cr0x@server:~$ cmd /c ver
Microsoft Windows [Version 10.0.19045.3803]
Що це означає: Вам потрібен номер збірки, оскільки поведінка SSU/LCU та відомі проблеми різняться за релізами.
Рішення: Якщо у вас стара збірка (або близько до кінця підтримки), заплануйте enablement update або feature update після стабілізації оновлень.
Task 2: Confirm the Windows Update services are present and running
cr0x@server:~$ powershell -NoProfile -Command "Get-Service wuauserv,bits,cryptsvc,msiserver | Format-Table -Auto Name,Status,StartType"
Name Status StartType
---- ------ ---------
wuauserv Stopped Manual
bits Running AutomaticDelayedStart
cryptsvc Running Automatic
msiserver Stopped Manual
Що це означає: wuauserv у стані Stopped не завжди є проблемою (воно може стартувати за тригером), але якщо він ніколи не стартує під час сканування, ви застрягли.
Рішення: Якщо bits або cryptsvc зупинені/відключені, виправте це спершу. Якщо служби відмовляються стартувати, переходьте до помилок у Event Viewer (Task 11).
Task 3: Start the core services and watch for immediate failure
cr0x@server:~$ cmd /c "net start wuauserv & net start bits & net start cryptsvc"
The Windows Update service is starting.
The Windows Update service was started successfully.
The Background Intelligent Transfer Service service is already running.
The Cryptographic Services service is already running.
Що це означає: Якщо служба відмовляється стартувати, ймовірно, у вас корупція, проблеми з дозволами або політичні обмеження.
Рішення: Якщо будь-яка служба падає з повідомленням «Access is denied» або «The service cannot be started», зупиніться тут і діагностуйте політику та ПЗ безпеки.
Task 4: Check if Windows thinks a reboot is pending
cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'; Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'"
True
False
Що це означає: True вказує на pending reboot від servicing (CBS). Це саме по собі може тримати вас у петлі.
Рішення: Перезавантажте один раз перед скиданням кешу. Якщо ви не можете перезавантажити (обмеження по обслуговуванню серверів), врахуйте, що ви відлагоджуєте зі зв’язаними руками.
Task 5: Pull the last 50 Windows Update client events for signal
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 50 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
2/5/2026 9:12:10 AM 20 Information Installation Successful: Windows successfully installed the following update...
2/5/2026 9:01:33 AM 31 Error The system failed to install the update with error 0x800f081f
Що це означає: Event ID 31 з 0x800f081f часто вказує на відсутні файли-джерела / проблеми component store.
Рішення: Якщо бачите повторювані успішні завантаження та провали інсталяцій, приділіть пріоритет DISM/SFC і ремонту component store (Tasks 9–10).
Task 6: Generate a readable WindowsUpdate.log on modern Windows
cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsUpdateLog -LogPath $env:TEMP\WindowsUpdate.log; Get-Item $env:TEMP\WindowsUpdate.log | Select-Object FullName,Length"
FullName Length
-------- ------
C:\Users\admin\AppData\Local\Temp\WindowsUpdate.log 284901
Що це означає: Тепер у вас є консолідований лог, збудований з ETW трас.
Рішення: Шукайте в ньому помилки, що починаються з 0x, та URL-адреси WSUS. Якщо знайдете внутрішні кінцеві точки оновлень, яких ви не очікували, переходьте до Task 8.
Task 7: Check for a WSUS policy forcing a non-existent update server
cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' /s"
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
WUServer REG_SZ http://wsus.corp.local:8530
WUStatusServer REG_SZ http://wsus.corp.local:8530
DisableWindowsUpdateAccess REG_DWORD 0x0
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
UseWUServer REG_DWORD 0x1
Що це означає: UseWUServer=1 примушує Use WSUS. Якщо цей сервер недоступний або неправильно налаштований, ви будете петляти вічно.
Рішення: Якщо ви в корпоративному середовищі, виправте доступність WSUS/proxy/схвалення. Якщо ви власник пристрою, можна видалити ключі політики (Task 8).
Task 8: Temporarily disable WSUS policy (only if you’re allowed)
cr0x@server:~$ powershell -NoProfile -Command "reg add 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' /v UseWUServer /t REG_DWORD /d 0 /f; net stop wuauserv; net start wuauserv"
The operation completed successfully.
The Windows Update service was stopped successfully.
The Windows Update service was started successfully.
Що це означає: Ви сказали агенту не використовувати WSUS. Це не перекреслює MDM в усіх випадках, і GPO може застосуватися згодом знову.
Рішення: Негайно запустіть сканування оновлень. Якщо воно працює, ваша петля була спричинена політикою/джерелом, а не корупцією.
Task 9: Repair the component store with DISM (the real workhorse)
cr0x@server:~$ powershell -NoProfile -Command "DISM /Online /Cleanup-Image /RestoreHealth"
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636
Image Version: 10.0.19045.3803
[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.
Що це означає: DISM виправив store або підтвердив, що він в порядку. Якщо воно падає з помилками джерела, можливо, знадобиться install.wim як джерело (Task 10).
Рішення: Якщо DISM вдалий, запустіть SFC далі. Якщо DISM падає, не повторюйте спроби сліпо — вирішіть проблему з джерелом.
Task 10: DISM with a known-good source (when Windows Update can’t provide it)
cr0x@server:~$ powershell -NoProfile -Command "DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:1 /LimitAccess"
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636
[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.
Що це означає: Ви використали інсталяційні носії як джерело для ремонту, уникаючи зламаних/заблокованих каналів оновлень.
Рішення: Якщо це вдалося там, де Task 9 зламався, ваше середовище блокує контент ремонту (WSUS без «Features on Demand», проксі або обмежені кінцеві точки).
Task 11: Run SFC to repair system files after DISM
cr0x@server:~$ cmd /c "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.
Що це означає: Захищені файли були пошкоджені і успішно відновлені, що може розблокувати servicing.
Рішення: Перезавантажте, потім спробуйте оновлення знову. Якщо SFC не може виправити файли, ви рухаєтесь у бік in-place repair install.
Task 12: Reset Windows Update cache safely (SoftwareDistribution and Catroot2)
cr0x@server:~$ cmd /c "net stop wuauserv & net stop bits & net stop cryptsvc & ren C:\Windows\SoftwareDistribution SoftwareDistribution.old & ren C:\Windows\System32\catroot2 catroot2.old & net start cryptsvc & net start bits & net start wuauserv"
The Windows Update service was stopped successfully.
The Background Intelligent Transfer Service service was stopped successfully.
The Cryptographic Services service was stopped successfully.
The Cryptographic Services service was started successfully.
The Background Intelligent Transfer Service service was started successfully.
The Windows Update service was started successfully.
Що це означає: Ви примусили Windows Update відбудувати свої кеші й крипто-каталоги.
Рішення: Запустіть сканування оновлень. Якщо петля зникла, кеш був пошкоджений. Якщо вона лишається, переходьте до глибших перевірок політик/servicing.
Task 13: Flush BITS jobs that can get “stuck”
cr0x@server:~$ powershell -NoProfile -Command "Get-BitsTransfer -AllUsers | Select-Object -First 5 DisplayName,JobState; Get-BitsTransfer -AllUsers | Remove-BitsTransfer"
DisplayName JobState
----------- --------
WU Client Download Transferring
Що це означає: BITS jobs можуть зависати або постійно падати; їх видалення змушує зробити чисту повторну спробу.
Рішення: Якщо бачите нескінченні стани Transferring/Error, очистіть їх і повторно проскануйте. Якщо вони одразу з’являються знову і падають, підозрюйте проксі/TLS inspection.
Task 14: Check disk space and free space on the system drive (yes, really)
cr0x@server:~$ powershell -NoProfile -Command "Get-PSDrive -Name C | Select-Object Used,Free | Format-List"
Used : 227.91 GB
Free : 1.84 GB
Що це означає: Низький вільний простір спричиняє падіння накопичувальних оновлень у спосіб, який UI не пояснює чітко.
Рішення: Якщо вільного місця менше ~10–15 GB на Windows 10, припиніть і звільніть простір перед продовженням. Інакше ви просто зробите більше логів і смутку.
Task 15: Verify time sync and certificate chain sanity
cr0x@server:~$ cmd /c "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 8:52:14 AM
Source: time.windows.com
Що це означає: Невірний час ламає TLS і валідацію підписів, що веде до помилок у каталогах і відомої петлі.
Рішення: Якщо час не синхронізований або суттєво неправильний, виправте це перед глибшою діагностикою корупції оновлень.
Task 16: Look for servicing stack / CBS errors in the CBS log
cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern 'error','0x800f','CSI' | Select-Object -First 10"
C:\Windows\Logs\CBS\CBS.log:... Error CSI 00000001 (F) 0x800f081f ...
C:\Windows\Logs\CBS\CBS.log:... Error CBS Failed to resolve package ...
Що це означає: CBS каже те, що GUI відмовляється: помилки вирішення пакетів і помилки component store.
Рішення: Повторювані 0x800f081f вказують на відсутні джерела; повторювані збої пакетів можуть інформувати про проблеми з порядком SSU/LCU або корупцією компонентів.
Жарт №1: Windows Update — єдиний співмешканець, який щомісяця просив плату за оренду і при цьому казав, що квартира не відповідає кодексу.
Common mistakes: symptom → root cause → fix
Тут більшість відлагоджень сходить нанівець: люди трактують кожну відмову як корупцію і починають видаляти папки.
Не робіть так. Зіставляйте симптоми з режимами відмов.
1) Symptom: Banner repeats after “You’re up to date” flashes briefly
- Root cause: Сканування оновлень завершується, але виявлення встановлення не проходить через pending reboot або невдале завершення постінсталяції.
- Fix: Перевірте ключі pending reboot (Task 4), перезавантажте, потім перевірте WindowsUpdateClient Operational події (Task 5).
2) Symptom: “Managed by your organization” and updates never progress
- Root cause: Політика WSUS/MDM, яка примушує внутрішнє джерело або правила відкладення; іноді напіввидалена конфігурація WSUS.
- Fix: Перевірте ключі політики (Task 7). Якщо дозволено, тимчасово відключіть UseWUServer (Task 8). Інакше виправляйте доступність/схвалення на стороні сервера.
3) Symptom: Downloads succeed, installs fail with 0x800f081f / 0x800f0831
- Root cause: Корупція component store або відсутнє джерело для ремонту; іноді пристрій не може дістатися контенту Microsoft через проксі/TLS inspection.
- Fix: DISM RestoreHealth (Task 9). Якщо воно падає, використайте WIM-джерело (Task 10). Потім запустіть SFC (Task 11).
4) Symptom: Error 0x8024a105 or random “try again later” behavior
- Root cause: Нестабільність Windows Update сервісу, перебої мережі або пошкоджений локальний кеш, що викликає повторні тайм-аути.
- Fix: Перезапустіть служби (Tasks 2–3), очистіть BITS jobs (Task 13), скиньте SoftwareDistribution/Catroot2 (Task 12).
5) Symptom: Update installs, then rolls back during reboot
- Root cause: Конфлікти драйверів, тиск дискового простору, помилки файлової системи або ПЗ безпеки, що змінює системні файли.
- Fix: Переконайтесь у вільному просторі (Task 14). Перевірте CBS log (Task 16). Розгляньте тимчасове вимкнення стороннього AV під час інсталяції (за політикою).
6) Symptom: Updates fail only on laptops off VPN
- Root cause: Конфлікт політик: WSUS обов’язковий, але доступний лише по VPN, або проксі-налаштування діють тільки в корпоративній мережі.
- Fix: Підтвердіть ключі WSUS (Task 7). Забезпечте правильний мережевий шлях або переведіть ці пристрої на Microsoft Update, коли вони поза VPN.
7) Symptom: “You are missing important fixes” but no updates appear in the list
- Root cause: Невідповідність метаданих виявлення, застряглий кеш оновлень або UI показує застарілий стан відповідності.
- Fix: Скиньте кеш (Task 12), згенеруйте WindowsUpdate.log (Task 6), проскануйте повторно.
8) Symptom: Everything looks normal, but the loop persists for months
- Root cause: Пристрій поза підтримкою / на збірці, яка не може отримувати певні оновлення, або потрібен feature update, щоб продовжити.
- Fix: Підтвердіть збірку (Task 1). Заплануйте feature update або in-place repair install. Перестаньте намагатися «виправити» непідтримувану базу.
Checklists / step-by-step plan
Checklist A: The minimal, safest sequence (most machines)
- Перевірте стан pending reboot (Task 4). Якщо pending — перезавантажте один раз.
- Переконайтесь, що служби не вимкнені (Task 2). Запустіть їх (Task 3).
- Перевірте журнал подій на наявність реального коду помилки (Task 5). Запишіть його.
- Перевірте вільне місце (Task 14). Якщо мало — звільніть простір перед продовженням.
- Запустіть DISM RestoreHealth (Task 9).
- Запустіть SFC (Task 11).
- Скиньте SoftwareDistribution + Catroot2 (Task 12).
- Перезавантаження.
- Скан і встановлення оновлень знову.
Checklist B: If the machine is “managed” (enterprise reality)
- Перевірте WSUS/WindowsUpdate ключі політик (Task 7).
- Підтвердіть, що джерело оновлень доступне (мережа/DNS/proxy). Не робіть припущень.
- Якщо дозволено, тимчасово встановіть
UseWUServer=0(Task 8), щоб ізолювати, чи проблема в WSUS. - Якщо проблема у WSUS, виправляйте на стороні сервера — схвалення/синхронізацію або цільову групу клієнтів — а не кеш клієнта.
- Якщо проблема не в WSUS, продовжуйте з DISM/SFC і скиданням кешу.
Checklist C: When DISM fails (don’t spiral)
- Захопіть помилку з виводу DISM і подій WindowsUpdateClient.
- Спробуйте DISM з WIM-джерелом і
/LimitAccess(Task 10). - Підтвердіть синхронізацію часу (Task 15) і проксі/TLS-обмеження.
- Якщо ремонти все ще не вдаються, заплануйте in-place repair install (збереже додатки/дані), замість нескінченних повторних спроб.
Жарт №2: Якщо ви видаляєте випадкові Windows-папки, щоб полагодити оновлення, ви фактично «збираєте сміття» за допомогою запальнички.
What to avoid (the stuff that makes it worse)
- Не запускайте «debloat» скрипти на продуктивних машинах, а потім не скаржтесь, що Windows Update зламався. Багато таких скриптів видаляють залежності обслуговування.
- Не вимикайте служби Windows Update назавжди, щоб «уникнути переривань». Ви отримаєте переривання пізніше, у найгірший можливий момент.
- Не користуйтесь сторонніми «фіксерами оновлень», які обіцяють ремонт в один клік. Вони часто просто видаляють кеші й приховують реальну причину.
- Не боріться з WSUS локальними хитрощами, якщо ви в керованому середовищі. GPO завжди в кінці кінців перемагає.
One operations quote (paraphrased idea)
перефразована ідея: Надія — це не стратегія.
— General H. Norman Schwarzkopf (часто цитують в операційній культурі; перефразовано)
FAQ
1) Is the “missing important security and quality fixes” message always accurate?
Воно точне в тому сенсі, що Windows вірить, що ви не повністю запатчені. Воно не надійно пояснює чому. Повідомлення — індикатор відповідності, а не діагностика.
2) Should I always reset SoftwareDistribution first?
Ні. Спочатку перевірте pending reboot і політику. Скидання кешів безпечне, але може замаскувати реальну проблему і коштувати вам часу на повторне завантаження великих накопичувальних оновлень.
3) What if I’m on a corporate laptop and don’t have admin rights?
Ви все ще можете зібрати сигнали: версію Windows (Task 1), записи Event Viewer (Task 5, якщо дозволено) і чи пристрій керується.
Потім передайте це в ІТ. Корисна частина — це код помилки і чи примушується WSUS.
4) Why does DISM sometimes hang at a percentage for a long time?
DISM виконує довготривалі операції обслуговування і може здаватися завислим, поки обробляє маніфести або ремонтує component store. Якщо продовжується активність диска — дайте йому час.
Якщо воно реально стоїть годинами без активності, можливо, проблеми з диском або файловою системою.
5) Do I need to install SSU before LCU?
Історично — так: спочатку SSU. На новіших збірках Windows 10 SSU і LCU часто поєднані або обробляються гладше, але залежності SSU все ще існують.
Якщо CBS логи скаржаться на компоненти servicing stack, ставте SSU як пріоритетну залежність.
6) Can antivirus or endpoint protection cause this loop?
Так. Деякі продукти перехоплюють системні зміни і можуть блокувати операції обслуговування, особливо під час перезавантажень. Чистий тест — тимчасово вимкнути продукт (якщо політика дозволяє) і спробувати знову.
Якщо це вирішує проблему, координуйте виняток або оновлення з командою безпеки.
7) I reset Windows Update components and it still loops. Now what?
Рухайтесь вгору по стеку: перевірте політику/WSUS, потім DISM з відомим добрим джерелом, потім розгляньте in-place repair install. Також перевірте вільне місце і синхронізацію часу — дві нудні причини, які видаються за «таємничу корупцію».
8) Will renaming Catroot2 break encryption or BitLocker?
Перейменування C:\Windows\System32\catroot2 — стандартний крок ремонту Windows Update і не ламає BitLocker.
Це змушує регенерувати каталоги для валідації оновлень. Потрібно зупинити cryptsvc перед цим (Task 12).
9) Why does it keep re-offering the same update?
Або оновлення ніколи не завершується (падає/відкочується), або Windows не може записати стан встановлення через проблеми component store.
Події в журналах та CBS покажуть, що саме. Повторені пропозиції зазвичай — проблема component store, а не завантаження.
10) When should I stop troubleshooting and re-image?
Якщо DISM з відомим добрим джерелом не вдається, SFC не може відновити, а CBS показує стійку корупцію пакетів, ви витрачаєте час на машину, яка більше не довіряє сама собі.
In-place repair install — ввічливий крок; реімідж — рішучий.
Next steps (keep it fixed)
Після того як ви розірвали петлю, не залишайте це як є. Зробіть виправлення стійким:
- Примушуйте перезавантаження після встановлення патчів. Банер любить машини, які ніколи не перезавантажуються.
- Моніторьте дисковий простір на кінцевих пристроях. C: з 2 GB вільного — передбачувана відмова, а не випадковість.
- Прибирайте дрейф політик: якщо WSUS використовується, підтримуйте його; якщо ні — видаліть ключі і припиніть робити вигляд, що він є.
- Стандартизовуйте плейбуки ремонту: DISM → SFC → скидання кешу, з логами до і після.
- Відстежуйте коди помилок з подій WindowsUpdateClient Operational. GUI — для відчуттів; логи — для фактів.
Якщо ви нічого більше не робите: запустіть швидкі діагностичні перевірки, спочатку виправляйте проблеми джерела/політики, потім ремонтуйте servicing, а потім скидайте кеші.
Такий порядок уникне марної роботи і виведе вас з петлі з найменшими побічними наслідками.