Microsoft heeft een probleem met het herstellen van Windows 11 herleid naar twee recente hotpatch-updates voor Windows 11 Enterprise LTSC 2024: KB5077212 van februari en KB5079420 van maart. Op getroffen systemen kan de functie "Deze pc opnieuw instellen" falen, ongeacht of de gebruiker kiest voor "Mijn bestanden behouden" of "Alles verwijderen."
Hoewel dit klinkt als een breed gedragen Windows-probleem, lijkt de impact in de praktijk specifieker te zijn.
De rapportage wijst op een scenario dat vooral de zakelijke markt raakt: commerciële apparaten die worden beheerd via Windows Autopatch, waarbij hotpatching is ingeschakeld, draaiend op Windows 11 24H2 en 25H2. Deze hotpatch-releases zijn door Microsoft officieel vermeld voor de builds 26100.7781 / 26200.7781 en 26100.7979 / 26200.7979, zoals ook gedocumenteerd in updates van Neowin en het Windows Forum.
De directe gevolgen zijn problematisch. Een poging om de pc opnieuw in te stellen kan resulteren in een zwart scherm, gevolgd door een foutmelding, of de computer start simpelweg opnieuw op in de bestaande omgeving zonder dat er wijzigingen zijn doorgevoerd. Een veelgehoorde melding is de bekende tekst: "Er is een probleem opgetreden bij het opnieuw instellen van de pc."
Wat Microsoft zegt en wat nog onduidelijk is
De kern van de zaak is dat KB5077212 en KB5079420 de "Push Button Reset" verstoren op bepaalde Windows 11-systemen. Diverse media melden dat Microsoft de ondersteuningsdocumentatie heeft bijgewerkt om dit te erkennen, zoals beschreven door Neowin en The Win Central.
Toch is er een nuance geplaatst bij dit nieuws: uit aanvullend onderzoek bleek dat de exacte bewoording waarin Microsoft beide KB-nummers expliciet als oorzaak aanwijst, niet altijd direct in openbare bronnen te reproduceren was zoals sommige koppen suggereerden. Dit betekent niet dat het probleem niet bestaat, maar precisie is belangrijk. De veiligste interpretatie is als volgt:
- Microsoft heeft een probleem erkend met Deze pc opnieuw instellen / Push Button Reset op het bewuste hotpatch-traject.
- Het probleem is gerelateerd aan de hotpatch-cyclus van februari en maart op Enterprise LTSC 2024-systemen die dit model gebruiken.
- Sommige gedetailleerde toeschrijvingen komen voort uit de interpretatie van ondersteuningsdocumenten en secundaire rapportages, en niet uit een uitgebreide publieke post-mortem van Microsoft.
Dit onderscheid is van belang omdat fouten in Windows-updates vaak worden versimpeld tot "update X sloopt functie Y". In werkelijkheid zit de fout vaak in aanverwante componenten, met name rondom het herstelsysteem.
Waarom dit lijkt op een WinRE-probleem in plaats van een reguliere desktopfout
De technische verklaring achter het probleem wijst op een verstoring van de Windows Recovery Environment (WinRE). Specifiek zou er sprake zijn van interferentie met provisioning packages en de paden naar de recovery images.
Dit is een vrij specifieke technische fout, wat ook aansluit bij de symptomen.
"Deze pc opnieuw instellen" is geen standaard desktopfunctie. Het is afhankelijk van herstelcomponenten, image-paden en een opstartproces dat losstaat van het normale besturingssysteem. Dit verklaart waarom deze machines dagelijks prima blijven draaien en maandelijkse hotpatches ontvangen, maar pas problemen vertonen wanneer een beheerder of gebruiker probeert de machine te herstellen.
Dit komt overeen met de oplossing die Microsoft adviseert: het installeren van KB5079471, een March Safe OS Dynamic Update. Dit type update is specifiek bedoeld voor de onderliggende structuur van Windows Setup en herstelprocessen, in plaats van een typische cumulatieve patch. Zowel de berichtgeving van Neowin over de update als rapportages van Windows News wijzen in die richting.
Dit is een belangrijk detail: wanneer de oplossing een Safe OS Dynamic Update is, bevindt de fout zich meestal in de herstel- of installatielaag en niet in het actieve besturingssysteem zelf.
De complexiteit van hotpatching
Hotpatching is ontworpen om verstoringen te verminderen. De belofte van Microsoft is helder: houd apparaten maandelijks beveiligd zonder elke keer een herstart te forceren. Voor veel zakelijke omgevingen is dit een enorme operationele winst.
Echter, hotpatching brengt ook extra afhankelijkheden en voorwaarden met zich mee. Volgens de richtlijnen van Microsoft moet voor hotpatching bijvoorbeeld VBS (Virtualization-based Security) ingeschakeld zijn. Voor Arm64-apparaten moet CHPE uitgeschakeld zijn, zoals vermeld in de Intune-documentatie voor hotpatch-configuratie en updates op Releasebot.
Dit betekent niet dat hotpatching inherent onbetrouwbaar is. Het suggereert wel dat wanneer er iets misgaat, de impact geconcentreerd is in omgevingen die al meer gespecialiseerd zijn dan de gemiddelde consumenten-pc.
Dat lijkt hier ook het geval. De rapportages geven aan dat consumentensystemen niet zijn getroffen. Het is dus minder een kwestie van "Windows 11 herstel is kapot" en meer "een specifiek zakelijk onderhoudspad heeft het herstelproces beschadigd op een subset van beheerde apparaten."
Dit blijft echter een serieuze zaak. In veel organisaties is Deze pc opnieuw instellen geen luxe, maar een essentieel onderdeel van de workflow voor ondersteuning en het opnieuw inzetten van hardware. Een bug die de desktop laat draaien maar stilletjes het herstelproces blokkeert, kan onopgemerkt blijven tot het kritieke moment dat een machine snel hersteld moet worden.
Een specifieke bug met grote gevolgen
Er is nog een reden waarom dit verhaal aandacht verdient: het valt samen met een moeizame periode voor de updates van Windows 11 24H2 en 25H2.
Volgens dezelfde bronnen heeft Microsoft op 1 april een rollback met betrekking tot KB5079391 gepauzeerd of ingetrokken, om vervolgens de out-of-band cumulatieve update KB5086672 uit te brengen om installatiefout 0x80073712 te verhelpen. Dit proces werd gevolgd door Notebookcheck, ZDNet en PCWorld.
Hoewel deze incidenten niet direct naar één onderliggende oorzaak wijzen, suggereren ze wel dat het onderhoud van 24H2/25H2 momenteel erg onrustig is: previews worden teruggetrokken, noodupdates worden verzonden en nu is er een defect in het herstelpad voor hotpatch-systemen.
Voor IT-teams is dit geen reden om hotpatching direct af te wijzen, maar het is wel een argument om herstelvalidatie als een apart proces te zien, los van de vraag of de machine opstart en de applicaties werken.
De kwestie rond Secure Boot
Een detail in de hotpatch van maart is makkelijk over het hoofd te zien: KB5079420 bevatte geen updates voor Secure Boot-certificaten, aangezien deze zijn uitgesteld naar de baseline-update van april 2026.
Hoewel dit niet de oorzaak lijkt van de reset-bug, illustreert het de complexe omgeving waarin beheerders werken. De vervanging van Secure Boot-certificaten is actueel omdat oudere Microsoft-certificaten in 2026 verlopen, een onderwerp waarover Microsoft en OEM's publiekelijk hebben geadviseerd via onder meer het Windows IT Pro-blog en de supportpagina over de status van certificaat-updates.
Het benadrukt dat zakelijk Windows-beheer momenteel niet alleen draait om maandelijkse beveiligingsupdates, maar ook om herstel-updates, hotpatch-baselines en certificaat-transities. Hoe meer lagen er zijn, hoe belangrijker het wordt dat de ene updatestroom de andere niet onbedoeld hindert.
Kenmerken van de getroffen systemen
Op basis van de documentatie van Microsoft en de bijbehorende rapportages ziet het profiel van getroffen systemen er als volgt uit:
Wat dit betekent voor beheerders
Er kunnen een paar praktische conclusies worden getrokken, met de kanttekening dat Microsoft werkt aan een definitieve oplossing.
Ten eerste: als uw apparaten niet op Enterprise LTSC 2024 met hotpatch via Autopatch draaien, is de kans groot dat dit probleem niet op uw omgeving van toepassing is. De rapportages wijzen consequent op een zeer specifiek onderhoudspad.
Ten tweede: als u dit pad wel gebruikt, is de belangrijkste test niet alleen of apparaten de nieuwste update accepteren en online blijven. De cruciale vraag is of herstelacties via WinRE nog steeds functioneren. Dit vereist een aparte validatiestap.
Ten derde: het advies van Microsoft om KB5079471 slechts eenmalig te implementeren, suggereert dat de huidige workaround een correctie is van de herstel-stack, en niet iets dat na elke maandelijkse patch herhaald hoeft te worden. Als deze richtlijn standhoudt, is het probleem beheersbaar.
De werkelijke les is specifieker dan de krantenkoppen doen vermoeden. Hotpatching doet wat het belooft door het aantal herstarts te verminderen. Maar dit incident laat de keerzijde zien: minder herstarts betekenen niet minder afhankelijkheden. En wanneer een van die afhankelijkheden WinRE is, kan een bug onzichtbaar blijven tot het moment dat een systeem redding nodig heeft.
Reacties