Windows Update greška 0x800f0922 (KB5089549)? Vodič za helpdesk timove 2026

Ažurirano: 12. srpnja 2026.

Windows Update greška 0x800f0922 na Windows 11 u 2026. najčešće znači da EFI System Partition (ESP) nema dovoljno slobodnog prostora za novu Windows Recovery Environment sliku koju uvodi kumulativno ažuriranje. Instalacija se sruši oko 35% tijekom faze ponovnog pokretanja, sustav se vraća na prethodno stanje i prikazuje poruku "Nešto nije pošlo prema planu. Poništavamo promjene." Iako je Microsoft izdao mitigaciju u KB5089573 (26. svibnja 2026.), fleet strojeva s 100 MB ESP-om (tipično HP EliteBook i Dell Latitude serije) i dalje udara u ovaj problem pri svakom Patch Tuesday izdanju. Iskreno, ovaj vodič je nastao nakon što sam prošli mjesec izgubio cijelu subotu vraćajući 40-ak EliteBookova na noge; ovdje su svi koraci dijagnostike, sigurnog oslobađanja prostora, službene Microsoftove mitigacije i prevencije za cijeli fleet.

• 0x800f0922 je CBS_E_INSTALLERS_FAILED. U 2026. najčešći uzrok je pun EFI System Partition, ne mrežni problem kao u ranijim godinama.
• Ažuriranja KB5089549 (svibanj 2026.) i KB5094126 (lipanj 2026.) najviše pogađaju Windows 11 24H2 i 25H2 strojeve s ≤10 MB slobodnog prostora na ESP-u.
• Provjerite ESP prostor jednom PowerShell naredbom prije bilo koje intervencije. Dijagnoza uvijek ide prije popravke.
• Službena mitigacija je KB5089573 plus registarska vrijednost EspPaddingPercent=0. Ne brišite datoteke iz EFI\Microsoft\Boot ručno bez pripreme.
• Za fleet od 100+ uređaja postavite ESP slobodan prostor kao metriku zdravlja, ne samo kao ad-hoc provjeru.
• Ako se instalacija stalno ruši, nemojte je ponavljati. Svaki pokušaj fragmentira disk i može oštetiti WinRE.

Što je greška 0x800f0922 i zašto se pojavljuje 2026.?

Greška 0x800f0922 ima interni naziv CBS_E_INSTALLERS_FAILED i znači da je Component-Based Servicing stack odustao od instalacije komponente. Najčešće se radi o Cumulative Updateu, Servicing Stack Updateu ili .NET Framework paketu. Kôd sam po sebi ne otkriva uzrok; morate ga sparen s Event Viewerom i C:\Windows\Logs\CBS\CBS.log da biste vidjeli što je stvarno palo.

U 2024. i 2025. tipični uzroci bili su nedostupan Windows Update server iza VPN-a, oštećena WinSxS komponenta ili neuspjeh App Readiness servisa. U 2026. slika se dramatično promijenila: Microsoft je zaoštrio provjeru slobodnog prostora na EFI System Partition jer novi Windows Recovery Environment (WinRE) image nadoknađuje sigurnosne dodatke iz Secure Boot revizije. Rezultat? Strojevi koji su godinama uredno primali ažuriranja odjednom se ruše na Patch Tuesday jer je ESP prenatrpan.

Zašto je to bitno za helpdesk? Većina korisnika i dalje čita "0x800f0922" i kreće s uobičajenim koracima (sfc /scannow, DISM, čišćenje cachea). Ti alati u ovom scenariju ne rade ništa jer nijedan sistemski file nije oštećen. Jednostavno nema mjesta za nove WinRE datoteke. Slično kao kod BitLocker ključa za oporavak na Windows 11, i ovdje je ključno prepoznati simptom: pogrešna dijagnoza znači sate izgubljenog vremena po tiketu.

Incidenti KB5089549 i KB5094126: što točno puca

Microsoft je 21. svibnja 2026. službeno potvrdio da KB5089549 (Windows 11 svibanjsko sigurnosno ažuriranje, izdano 12. svibnja) ne uspijeva instalirati na dijelu 24H2 i 25H2 uređaja. Simptomi su konzistentni: instalacija napreduje normalno do faze offline primjene, sustav se restarta, staje na ~35% i vraća se s greškom 0x800f0922. Fleet-podaci pokazali su da su najpogođeniji modeli s ESP-om od 100 MB, konkretno HP EliteBook 840 G7 i G8, Dell Latitude 5000/7000 serije, kao i starije Surface Pro generacije koje su nadograđene s Windowsa 10.

Lipanjski KB5094126 nastavio je isti obrazac. Iako Microsoft tvrdi da KB5089573 (izdan 26. svibnja 2026.) rješava korijenski uzrok kroz Known Issue Rollback (KIR), enterprise strojevi kojima upravlja WSUS ili Intune moraju posebno primijeniti Group Policy da bi mitigacija stigla. Mnoge organizacije to nisu učinile do lipanjskog Patch Tuesdaya, pa se scenarij ponovio.

Prepoznavanje u CBS.log

Otvorite C:\Windows\Logs\CBS\CBS.log nakon neuspjelog pokušaja i tražite retke poput ovih:

[HRESULT = 0x80070070 - ERROR_DISK_FULL]
Error CBS Failed to stage EFI package. HRESULT: 0x800f0922
CBS Reboot mark: STATE_REBOOT_PENDING (from ESP staging)

Kombinacija ERROR_DISK_FULL i ESP staging u istom vremenskom prozoru je smoking gun. Ako umjesto toga vidite ERROR_TIMEOUT ili WU_E_PT_HTTP_STATUS_*, radi se o mrežnom uzroku (VPN, proxy, DNS), a ne ESP-u.

Dijagnoza: kako provjeriti slobodan prostor na EFI particiji

Prije bilo koje intervencije, izmjerite prostor. Najbrža jednolinerska naredba u PowerShellu (pokrenite kao Administrator):

# PowerShell - provjera slobodnog prostora na EFI System Partition
Get-Partition |
  Where-Object GptType -eq '{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}' |
  Get-Volume |
  Select-Object DriveLetter, FileSystemLabel,
                @{n='SizeMB';    e={[math]::Round($_.Size/1MB,1)}},
                @{n='FreeMB';    e={[math]::Round($_.SizeRemaining/1MB,1)}},
                @{n='FreePercent'; e={[math]::Round(($_.SizeRemaining/$_.Size)*100,1)}}

Interpretacija:

• > 40 MB slobodno na 100 MB ESP-u. Vjerojatno ćete preživjeti sljedeći Patch Tuesday.
• 10–40 MB slobodno. U opasnoj zoni. Očistite prostor prije nego što aplicirate iduće ažuriranje.
• < 10 MB slobodno. Praktički zajamčen 0x800f0922 na sljedećem CU-u. Djelujte odmah.

Ako trebate montirati ESP da vidite što je unutra, koristite mountvol:

:: Command Prompt (Administrator)
mountvol S: /S
dir S:\EFI\Microsoft\Boot /s /a
:: Nakon pregleda, uvijek odmontirajte:
mountvol S: /D

Fleet dijagnostika za više uređaja

Ako upravljate s više od nekoliko strojeva, ne ide vam jedan po jedan. Skripta ispod izvještaj piše u CSV pogodan za uvoz u Intune ili PowerBI:

# Fleet ESP inventory - pokrenuti kao Intune Proactive Remediation ili SCCM CI
$computerName = $env:COMPUTERNAME
$esp = Get-Partition |
  Where-Object GptType -eq '{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}' |
  Get-Volume | Select-Object -First 1

if ($null -eq $esp) {
  Write-Output "$computerName,NO_ESP_FOUND,0,0,0"
  exit 1
}

$sizeMB   = [math]::Round($esp.Size / 1MB, 1)
$freeMB   = [math]::Round($esp.SizeRemaining / 1MB, 1)
$freePct  = [math]::Round(($esp.SizeRemaining / $esp.Size) * 100, 1)
$risk     = if ($freeMB -lt 10) { 'CRITICAL' }
            elseif ($freeMB -lt 40) { 'AT_RISK' }
            else { 'OK' }

Write-Output "$computerName,$risk,$sizeMB,$freeMB,$freePct"
if ($risk -eq 'CRITICAL') { exit 1 } else { exit 0 }

Postavite ovu skriptu kao Proactive Remediation Detection u Intuneu (vidi naš Intune priručnik za helpdesk timove za korake konfiguracije). Rizične strojeve prijavljujete u ticketing sustav prije nego što korisnik prijavi problem.

Službena Microsoft mitigacija (KB5089573 + registarski ključ)

Microsoft je 26. svibnja 2026. objavio KB5089573 kao Optional Preview koji smanjuje rezervirani padding u ESP-u tijekom servisiranja s ~30% na 0%. Ista logika je uključena u sva kasnija kumulativna ažuriranja od srpnja 2026. nadalje.

Konzumerski i unmanaged strojevi

Automatski dobivaju KIR (Known Issue Rollback) unutar 24 do 48 sati od instalacije KB5089573. Ako korisnik ne primi mitigaciju automatski, ručno postavite ovaj registarski ključ:

:: Command Prompt (Administrator)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Bfsvc" ^
  /v EspPaddingPercent /t REG_DWORD /d 0 /f

:: Restart obavezan prije ponovnog pokušaja azuriranja:
shutdown /r /t 5

Nakon restarta pokrenite Settings > Windows Update > Check for updates i pustite instalaciju.

Enterprise strojevi (WSUS, Intune, SCCM)

Za strojeve iza enterprise policyja, KIR ne stiže automatski. Trebate primijeniti odgovarajuću Group Policy koju Microsoft distribuira uz KB. U Intuneu:

1. Otvorite Devices > Configuration profiles > Create profile.
2. Odaberite Windows 10 and later → Templates → Administrative Templates.
3. Idite na Computer Configuration > Windows Components > Windows Update > Known Issue Rollback.
4. Uključite politiku KB5089549 240508_02330 Rollback (točan naziv može se razlikovati, provjerite u Microsoftovim službenim uputama za grešku 0x800f0922).
5. Dodijelite profil ciljnoj grupi uređaja i restartajte.

Kako sigurno osloboditi prostor na EFI particiji

Ako mitigacija ne dolazi ili je hitna intervencija (npr. korisnik na produkcijskom stroju), sigurno možete ukloniti nekoliko elemenata iz ESP-a bez rušenja boota.

1. Neaktivni jezični folderi

Windows piše bootloader stringove u više jezika u EFI\Microsoft\Boot\. Sigurno je zadržati samo onaj koji odgovara jeziku sustava:

:: Command Prompt (Administrator) - BACKUP PRIJE BRISANJA
mountvol S: /S
robocopy S:\EFI\Microsoft\Boot C:\ESP-Backup\Boot /E
:: Provjerite koji jezik koristi vas sustav (npr. hr-HR ili en-US):
dir S:\EFI\Microsoft\Boot\ /AD

:: Uklonite samo one jezike koje sigurno ne koristite:
rmdir /s /q S:\EFI\Microsoft\Boot\fr-FR
rmdir /s /q S:\EFI\Microsoft\Boot\de-DE
rmdir /s /q S:\EFI\Microsoft\Boot\es-ES
:: NIKAD ne brisite hr-HR ako je sustav na hrvatskom, ni en-US kao fallback.

mountvol S: /D

Tipičan prinos: 15 do 25 MB slobodnog prostora, dovoljno za instalaciju idućeg CU-a. Meni je na EliteBook 840 G8 fleetu ovo bilo dovoljno da preskočim cijeli lipanjski incident bez pojedinačnog dodirivanja stroja.

2. Stari WinRE snapshot

Neki 24H2 uređaji imaju zaostali stari WinRE. Ne dirajte ga direktno. Umjesto toga koristite reagentc koji zna sigurno rekonstruirati Recovery Environment:

:: Provjerite trenutni WinRE status:
reagentc /info

:: Ako je Recovery lokacija u Windows particiji, mozete privremeno onemoguciti:
reagentc /disable
:: Ovo oslobada WinRE.wim iz ESP-a. Ponovo ukljucite tek nakon uspjesnog azuriranja:
reagentc /enable

3. Proširenje EFI particije (napredno)

Ako trebate trajno rješenje, proširite ESP na 260 MB (Microsoftov preporučeni minimum za nove uređaje). ESP mora biti fizički uz particiju koju smanjujete. Standardni Disk Management to ne može, trebate alat poput MiniTool Partition Wizard ili AOMEI Partition Assistant. Prije nego što krenete, napravite puni image sustava, jer neuspjelo pomicanje bootabilne particije završava non-bootable strojem.

Alternativni uzroci: NET Framework, VPN i oštećene komponente

Ako CBS.log ne pokazuje ERROR_DISK_FULL, ESP nije problem. Preostali uzroci se svode na tri kategorije.

Oštećen .NET Framework paket

0x800f0922 se povijesno vezao za neuspjelu instalaciju .NET-a. Popravak:

:: Skenirajte i popravite komponentni store:
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

:: Ako je specificno .NET, koristite Microsoftov .NET Repair Tool:
:: preuzmite s aka.ms/dotnetrepairtool i pokrenite kao Administrator

VPN ili proxy blokira Windows Update servere

Ako je stroj spojen na korporativni VPN, promet prema windowsupdate.microsoft.com, *.windowsupdate.com i *.microsoft.com može ići kroz proxy koji baca dijelove sadržaja. Provjerite jesu li ti hostovi na VPN split-tunnel exclusion listi. Ako ne rješavate mrežni problem, pogledajte i naš vodič za rješavanje VPN problema na Windows 11. Isti uzorak DNS ili MTU problema koji ruši VPN često sabotira i Windows Update.

App Readiness servis onemogućen

Rjeđi ali stvaran uzrok. Ispravak:

:: PowerShell (Administrator)
Set-Service -Name AppReadiness -StartupType Manual
Start-Service -Name AppReadiness
Get-Service AppReadiness  # ocekivano: Running / Manual

Kako resetirati Windows Update komponente

Ako ništa od gore navedenog ne pomaže (a to je stvarno zadnja linija obrane, ne prvi korak), resetirajte Windows Update stack. Ova skripta zaustavlja servise, briše cache i restarta ih redoslijedom koji ne ostavlja polovične datoteke:

:: reset-wu.cmd - pokrenite kao Administrator
@echo off
echo Zaustavljam Windows Update servise...
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

echo Uklanjam cache foldere...
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old

echo Pokrecem servise ponovno...
net start wuauserv
net start cryptSvc
net start bits
net start msiserver

echo Gotovo. Otvorite Settings ^> Windows Update i pokusajte ponovno.

Nakon resetiranja pokrenite Check for updates. Ako se greška vrati identično, imate potvrdu da problem nije u cacheu, pa se vratite na dijagnozu ESP-a.

Fleet prevencija i monitoring za IT timove

Za helpdesk koji upravlja s više od 50 uređaja, reaktivno rješavanje 0x800f0922 tiketa je gubljenje vremena. Postavite tri sloja prevencije (ili četiri, ako pridodate komunikaciju s korisnicima).

Sloj 1: ESP kao metrika fleet zdravlja

Skriptu iz dijela Dijagnoza deployajte kao Intune Proactive Remediation ili SCCM Configuration Item s tjednim rasporedom. U dashboardu pratite postotak uređaja s CRITICAL statusom (≤10 MB slobodno). Cilj: 0 CRITICAL uređaja prije svakog Patch Tuesdaya.

Sloj 2: Automatska remedijacija za enterprise

Uz Detection skriptu, postavite Remediation script koji na CRITICAL uređajima automatski primijeni registarski EspPaddingPercent=0 ključ i, ako politika dozvoli, ukloni neaktivne jezične boot foldere. Testirajte na pilot grupi od 10 do 20 strojeva prije šireg deploya.

Sloj 3: Uzorak novih uređaja

Kod naručivanja novih uređaja od OEM-a inzistirajte na 260 MB ESP u tvorničkom imageu. Ako radite vlastite imageove kroz Autopilot ili MDT, mijenjajte particijsku shemu unattend.xml-om. Microsoftove upute za UEFI/GPT partition layout daju točnu strukturu.

Sloj 4: Komunikacija s korisnicima

Kad Patch Tuesday izađe, pošaljite kratku advisory poruku IT-friendly korisnicima (dev tim, ops, sysadmini):

• Ne restartajte silom tijekom "instalacije ažuriranja".
• Ako vidite "Undoing changes", zabilježite točan trenutak i otvorite tiket. Nemojte pokušavati instalaciju sami.
• Nemojte instalirati third-party disk cleanupe koji "čiste" ESP. Često oštećuju WinRE.

Kombinacijom ova četiri sloja tipičan helpdesk smanjuje 0x800f0922 tikete za 80 do 90% u tri mjeseca. Više o strukturiranju proaktivne remedijacije naći ćete u Microsoft Tech Community Intune sekciji, gdje inženjeri redovito objavljuju spremne skripte za slične incidente.

Često postavljana pitanja

Kako popraviti grešku 0x800f0922 na Windows 11 24H2?

Prvo provjerite slobodan prostor na EFI System Partition PowerShell naredbom Get-Partition | Where-Object GptType -eq '{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}' | Get-Volume. Ako je slobodno <10 MB, primijenite Microsoftov registarski ključ EspPaddingPercent=0 ili ručno očistite neaktivne jezične boot foldere. Instalirajte KB5089573 ili noviji CU koji sadrži KIR mitigaciju.

Je li sigurno postaviti EspPaddingPercent na 0?

Da, to je službena Microsoftova mitigacija za incident iz svibnja 2026. Registarski ključ smanjuje rezervirani padding koji Windows koristi tijekom servisiranja ESP-a, a nova ažuriranja od srpnja 2026. već ugrađuju istu logiku. Ključ ostavite trajno, čak i nakon KB5089573, jer postaje no-op.

Mogu li obrisati datoteke iz EFI\Microsoft\Boot foldera?

Nikad ne brišite bootmgfw.efi, bootmgr.efi ni jezični folder koji odgovara jeziku sustava, stroj se neće pokrenuti. Sigurno je ukloniti samo neaktivne jezične foldere (npr. fr-FR, de-DE) ako sustav ne koristi te jezike. Uvijek prvo napravite backup ESP-a i System Restore točku.

Zašto samo neki HP EliteBook i Dell Latitude modeli imaju ovaj problem?

Ti modeli su tvornički isporučivani s 100 MB EFI System Partition, što je nekad bio industrijski standard. Nakon 5+ godina kumulativnih ažuriranja i sigurnosnih dodataka za Secure Boot, prostor se popuni. Noviji uređaji imaju 260 MB ESP i praktički nikad ne udaraju u ovaj problem.

Koliko traje Microsoftova KIR mitigacija da stigne?

Za konzumerske i unmanaged Windows 11 uređaje mitigacija stiže automatski unutar 24 do 48 sati od instalacije KB5089573. Enterprise strojevi iza Intune, WSUS ili SCCM zahtijevaju eksplicitno primjenjivanje Group Policy. Bez toga KIR ne aktivira i uređaj i dalje udara u 0x800f0922 na sljedećim ažuriranjima.