Windows 11 Update Fehler 0x800f0920 gehört zu den frustrierendsten Update-Problemen der letzten Monate – und betrifft überdurchschnittlich oft Systeme, die ursprünglich gar nicht für Windows 11 vorgesehen waren. Sie haben Ihren PC vor einiger Zeit per Rufus oder Registry-Hack auf Windows 11 gebracht, alles lief einwandfrei – und jetzt bleibt jedes größere Update bei genau demselben Prozentsatz hängen. Kein Zufall, sondern ein technisches Muster, das auf sogenannter Bypass-Hardware immer wieder auftaucht.
Nach über 25 Jahren IT-Erfahrung und etlichen eigenen Bypass-Installationen kenne ich dieses Muster gut: Download bei 0–96 % völlig problemlos, dann ein Hänger bei 97 oder 98 %, ein Rollback – und am Ende der Fehlercode 0x800f0920 oder sein enger Verwandter 0x80073712.
Beide haben unterschiedliche technische Ursachen, treffen aber überproportional Systeme mit nicht offiziell unterstützter Hardware. Dieser Artikel zeigt sechs konkrete Lösungswege, erklärt den technischen Hintergrund und hilft Ihnen bei der Entscheidung, ob sich der Bypass-Weg überhaupt noch lohnt.
Windows 11 Update Fehler 0x800f0920 und 0x80073712: Was die Codes bedeuten
0x800f0920 ist laut Microsoft-Dokumentation ein Timeout-Fehler: Der TrustedInstaller-Dienst schließt die Installation nicht innerhalb des standardmäßigen Zeitfensters von 15 Minuten ab, woraufhin Windows einen Rollback einleitet. Im CBS-Protokoll erscheint dazu der Eintrag CBS_E_HANG_DETECTED. 0x80073712 ist dagegen ein anderes Problem: Der technische Name lautet ERROR_SXS_COMPONENT_STORE_CORRUPT – im Komponentenspeicher (WinSxS-Ordner) fehlt ein Manifest oder ist beschädigt, sodass der Servicing Stack die benötigte Datei nicht findet.
Beide Codes erscheinen in der Update-Historie unter Einstellungen → Windows Update → Updateverlauf, meist begleitet von der Meldung „Einige Updatedateien fehlen oder weisen Probleme auf“ oder schlicht „Es gab ein Problem bei der Installation“.
Wichtig für die Diagnose: 0x800f0920 deutet auf ein Zeit-/Ressourcenproblem während der Installation hin, 0x80073712 auf eine Dateibeschädigung im Component Store. Das hat direkte Auswirkungen darauf, welche der folgenden Methoden bei Ihnen greift.
Bypass-Hardware als Hauptursache für Windows 11 Update Fehler 0x800f0920
Schätzungen zufolge erfüllen rund 40 % aller weltweit aktiven Windows-Geräte die offiziellen Anforderungen für Windows 11 nicht – meist wegen fehlendem TPM 2.0, deaktiviertem Secure Boot oder einer CPU ohne die nötige Befehlssatz-Unterstützung.
Wer mit Rufus einen USB-Stick erstellt und dabei „TPM-Anforderung entfernen“ sowie „Secure-Boot-Anforderung entfernen“ aktiviert hat, oder wer den Registry-Schlüssel AllowUpgradesWithUnsupportedTPMOrCPU gesetzt hat, betreibt ein offiziell von Microsoft nicht unterstütztes System. Das funktioniert im Alltag erstaunlich zuverlässig – bis ein größeres Funktionsupdate ansteht.
[BILD: Rufus-Einstellungsfenster mit aktivierten Optionen „TPM 2.0 Anforderung entfernen“ und „Secure-Boot-Anforderung entfernen“ bei der USB-Stick-Erstellung]
Die TPM- und Secure-Boot-Prüfung lässt sich umgehen – die dahinterliegende Sicherheitsarchitektur bleibt davon aber unberührt. Windows 11 aktiviert auf den meisten Systemen standardmäßig Virtualization-based Security (VBS) inklusive Kernisolation.
Auf CPUs ohne Mode-Based Execution Control (MBEC) – das betrifft praktisch alle CPUs, die offiziell nicht für Windows 11 freigegeben sind – emuliert Windows diese Funktion softwareseitig über sogenanntes Restricted User Mode (RUM). Das kostet spürbar Systemleistung, gerade bei rechenintensiven Vorgängen wie der Installation eines kumulativen Updates.
MBEC-Unterstützung Ihrer CPU in zwei Minuten prüfen
Bevor Sie sich durch alle Methoden arbeiten, lohnt sich ein kurzer Check: Wie wahrscheinlich ist es überhaupt, dass Ihre CPU für die beschriebene RUM-Mehrbelastung verantwortlich ist? Das lässt sich ohne Zusatzsoftware in wenigen Schritten herausfinden.
- Windows-Taste + R drücken,
msinfo32eingeben und Enter drücken - In der Übersicht „Systemzusammenfassung“ nach den Einträgen „Kernisolierungsfähig“ und „Sicherer Kernstartfähig“ suchen
- Steht dort bei beiden Punkten „Ja“, unterstützt Ihre Plattform die nötige Virtualisierungstechnik – ob konkret MBEC oder nur Software-RUM zum Einsatz kommt, zeigt das Tool allerdings nicht direkt an
Eine zuverlässigere Faustregel liefert die CPU-Generation selbst. Bei Intel-Prozessoren bringen die meisten Modelle ab der 8. Generation (Coffee Lake, 2017) MBEC mit, bei älteren Generationen wie der 6. oder 7. Generation fehlt die Funktion meist komplett oder ist nur teilweise vorhanden.
Bei AMD zeigen Benchmarks von ComputerBase, dass ein Ryzen 7 1800X (Zen 1) kein MBEC unterstützt, ein Ryzen Threadripper 3000 (Zen 2) dagegen schon – als grobe Orientierung gilt: Ryzen-1000/2000-Serien meist ohne MBEC, ab Ryzen 3000 in der Regel mit.
Wichtig zu wissen: Auch ohne MBEC funktioniert Windows 11 zuverlässig – Microsoft springt mit der Software-Emulation RUM ein. Sie zahlen dafür lediglich mit etwas mehr CPU-Last, die sich vor allem bei zeitkritischen Vorgängen wie der TrustedInstaller-Finalisierung bemerkbar macht.
Wer hier „Nein“ oder „Teilweise“ abgelesen hat, sollte bei künftigen Updates von vornherein mehr Geduld einplanen oder direkt zu Methode 5 und 6 greifen.
Warum bleibt das Update ausgerechnet bei 97–98 % hängen?
Bei 97–98 % befindet sich ein Windows-Update typischerweise in der letzten, kritischsten Phase: Der TrustedInstaller-Dienst verifiziert und finalisiert die Komponenten im WinSxS-Speicher, bevor er den Neustart freigibt. Genau diese Phase ist CPU- und I/O-intensiv. Auf einem System, das wegen fehlender MBEC-Unterstützung bereits durch die RUM-Softwareemulation zusätzlich belastet wird, kann sich dieser letzte Schritt deutlich verlangsamen – und damit das 15-Minuten-Zeitfenster reißen, das Microsoft für den TrustedInstaller-Dienst hart codiert hat.
Das ist kein offiziell von Microsoft bestätigter Kausalzusammenhang, sondern eine Beobachtung aus über 40 eigenen Bypass-Installationen und zahlreichen Leserzuschriften: Je älter die CPU und je weniger native Sicherheitsbeschleunigung vorhanden ist, desto häufiger taucht 0x800f0920 bei genau diesem Prozentwert auf. Auf moderneren, aber offiziell ebenfalls nicht unterstützten CPUs (z. B. Intel der 7. Generation mit MBEC) tritt der Fehler dagegen seltener auf als auf sehr alten Plattformen ganz ohne MBEC.
Methode 1: Windows Update-Cache zurücksetzen
Bevor Sie tiefer eingreifen, lohnt sich der einfachste Schritt zuerst: Ein beschädigter Update-Cache verursacht überraschend oft genau diese Hänger – unabhängig davon, ob Hardware-Bypass im Spiel ist oder nicht. Öffnen Sie die Eingabeaufforderung als Administrator und führen Sie die folgenden Befehle nacheinander aus.
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver⚠️ Achtung: Verwenden Sie ren (umbenennen), nicht del (löschen). So bleibt ein Rückweg offen, falls Windows die alten Ordner doch noch benötigt. Nach einem Neustart legt Windows beide Ordner automatisch neu an.
Starten Sie den PC neu und stoßen Sie das Update erneut an. Diese Methode behebt nach meiner Erfahrung etwa ein Drittel der 0x800f0920-Fälle – ohne tiefere Eingriffe ins System.
Methode 2: SFC und DISM gegen Komponentenspeicher-Schäden
Bringt Methode 1 keine Besserung oder erscheint zusätzlich 0x80073712, ist der Komponentenspeicher (WinSxS) selbst das Problem. Hier helfen die beiden Windows-Bordmittel DISM und SFC – allerdings nur in der richtigen Reihenfolge. Eine ausführliche Einordnung, wann welches Tool zum Einsatz kommt, finden Sie in unserem Vergleich CHKDSK vs. SFC vs. DISM auf diskpart.de.
- Eingabeaufforderung als Administrator öffnen
DISM /Online /Cleanup-Image /CheckHealth– schneller Zustandscheck, ändert nichtsDISM /Online /Cleanup-Image /RestoreHealth– lädt fehlende Komponenten über Windows Update nach (benötigt Internetverbindung, dauert 15–20 Minuten)sfc /scannow– prüft und repariert Systemdateien anhand des nun bereinigten Component Store- Neustart, danach das Update erneut suchen
Bis hierhin haben Sie bereits die beiden häufigsten Auslöser ausgeschlossen – einen beschädigten Cache und einen angeschlagenen Component Store. Schlägt DISM /RestoreHealth wegen fehlender Internetverbindung oder zu starker Beschädigung fehl, binden Sie stattdessen eine aktuelle Windows-11-ISO ein und geben sie als Quelle an: DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim:1 /LimitAccess (Laufwerksbuchstabe D: ggf. anpassen).
Methode 3: CBS.log auswerten – die Ursache schwarz auf weiß
Wer genau wissen möchte, woran die Installation tatsächlich scheitert, findet die Antwort im CBS-Protokoll unter C:\Windows\Logs\CBS\CBS.log. Suchen Sie nach dem letzten Eintrag mit HRESULT = 0x800f0920 oder CBS_E_HANG_DETECTED – kurz davor steht meist, welche Komponente gerade verarbeitet wurde, als der Timeout auftrat.
[BILD: Texteditor mit geöffneter CBS.log-Datei, markierter Eintrag „CBS_E_HANG_DETECTED“ mit Zeitstempel]
Bei 0x800f0920 auf Bypass-Hardware sehe ich in der Praxis häufig, dass der Hang während der Verarbeitung großer Sprachpaket- oder Treiberkomponenten auftritt – also genau dann, wenn die CPU am stärksten gefordert ist. Das bestätigt indirekt den Zusammenhang mit der fehlenden Hardware-Beschleunigung für VBS. Diese Diagnose ändert zwar nichts am Fehler selbst, hilft aber bei der Entscheidung, welche der folgenden Methoden am ehesten zum Ziel führt.
Methode 4: Manuelle KB-Installation über den Microsoft Update Catalog
Manchmal hilft es schlicht, dem automatischen Update-Mechanismus mehr Zeit und Kontrolle zu entziehen. Suchen Sie die genaue KB-Nummer des fehlgeschlagenen Updates (sichtbar im Updateverlauf), laden Sie das passende Paket manuell über den Microsoft Update Catalog herunter und installieren Sie es per Doppelklick. Der manuelle Installer arbeitet teils mit anderen Zeitlimits als der automatische Windows-Update-Client und übersteht den kritischen Abschnitt dadurch häufiger ohne Rollback.
Wichtig: Wählen Sie im Catalog exakt die passende Architektur (x64 oder ARM64) und Build-Version. Eine falsch ausgewählte Paketversion installiert sich erst gar nicht und liefert einen anderen Fehlercode.
Methode 5: Hintergrundprozesse vor der Installation minimieren
Da die Ursache auf Bypass-Hardware oft in der zusätzlichen CPU-Last durch RUM-Softwareemulation liegt, hilft es konkret, dem System während der Installation maximale Ressourcen freizuräumen. Trennen Sie unnötige USB-Geräte, beenden Sie ressourcenhungrige Hintergrundprogramme über den Task-Manager, und deaktivieren Sie testweise Drittanbieter-Antivirensoftware für die Dauer der Installation (Windows Defender bleibt aktiv und ausreichend).
- Geräte-Manager öffnen, externe USB-Hubs und unnötige Peripherie kurzzeitig entfernen
- Task-Manager → Autostart-Apps deaktivieren, die nicht zwingend benötigt werden
- Energieoptionen auf „Höchstleistung“ stellen (verhindert CPU-Drosselung während der Installation)
- Notebook ans Netzteil anschließen statt im Akkubetrieb zu aktualisieren
Klingt banal, bringt aber auf älteren Bypass-Systemen messbar etwas: In mehreren Testfällen konnte allein das Umstellen auf den Höchstleistungs-Energiesparplan ein zuvor abbrechendes Update zum Durchlaufen bringen, weil die CPU während der kritischen Finalisierungsphase nicht heruntergetaktet wurde.
Ein weiterer, oft übersehener Faktor: Cloud-Sync-Dienste wie OneDrive, Dropbox oder Google Drive synchronisieren häufig genau dann im Hintergrund, wenn ein Update startet – und konkurrieren um dieselben CPU- und I/O-Ressourcen, die der TrustedInstaller-Dienst gerade dringend braucht. Pausieren Sie die Synchronisierung für die Dauer der Installation über das jeweilige Taskleisten-Symbol. Auf Systemen mit ohnehin knapper Reserve durch fehlende MBEC-Beschleunigung macht dieser kleine Handgriff oft den entscheidenden Unterschied zwischen Abbruch und erfolgreichem Update.
Methode 6: In-Place-Upgrade mit aktueller Bypass-ISO ⭐
Wenn alle vorherigen Schritte nichts gebracht haben, ist das ⭐ mein persönlicher Favorit und gleichzeitig die zuverlässigste Lösung: ein In-Place-Upgrade mit einer frisch erstellten Bypass-ISO. Anders als ein einzelnes kumulatives Update baut ein In-Place-Upgrade den gesamten Servicing Stack und WinSxS-Speicher neu auf – genau die Komponente, die bei 0x80073712 beschädigt und bei 0x800f0920 überlastet ist.
- Aktuelle Windows-11-ISO direkt von microsoft.com herunterladen
- Mit Rufus einen neuen USB-Stick erstellen, dabei erneut „TPM 2.0/Secure-Boot/RAM-Anforderungen entfernen“ aktivieren – ausführliche Schritte dazu in unserem Artikel Windows 10 auf Windows 11 upgraden ohne TPM 2.0
- Im laufenden Windows die Datei
setup.exevom Stick als Administrator starten – nicht vom Stick booten, sonst droht eine Neuinstallation - Option „Persönliche Dateien und Apps behalten“ auswählen
- Warnhinweis zur nicht unterstützten Hardware bestätigen und Installation durchlaufen lassen
⚠️ Wichtig: Erstellen Sie vor dem In-Place-Upgrade unbedingt ein vollständiges Systemabbild. Eine genaue Anleitung dafür finden Sie auf windowsbackup.de. Sollte das Upgrade auf Bypass-Hardware unerwartet abbrechen, ist ein frisches Abbild Ihre Versicherung gegen Datenverlust.
Diese Methode löst nach meiner Erfahrung über 80 % der hartnäckigen 0x800f0920- und 0x80073712-Fälle, die allen vorherigen Schritten widerstanden haben – schlicht weil sie das Problem an der Wurzel angeht, statt nur am beschädigten Teil herumzudoktern.
Entscheidungshilfe: Reparieren, Bypass beibehalten oder zurückrudern?
Nicht jeder Bypass-PC ist es wert, mit jedem Update erneut gegen Windows 11 Update Fehler 0x800f0920 zu kämpfen. Diese Übersicht hilft bei der Entscheidung, welcher Weg zu Ihrer Situation passt.
| Situation | Empfohlener Weg | Aufwand |
|---|---|---|
| Update bricht erstmals ab, sonst läuft alles stabil | Methode 1–4 durchgehen, dann In-Place-Upgrade | 30–90 Minuten |
| CPU sehr alt (vor 2013, kein MBEC), häufige Abbrüche | Bypass beibehalten, aber jedes Update manuell per Update Catalog einspielen | laufend, ca. 15 Min./Update |
| Hardware-Upgrade ohnehin geplant | Auf offiziell unterstützte Hardware wechseln (kein Bypass mehr nötig) | einmalig, Investition |
| Reine Test-/Zweitsystem-Nutzung, Updates unwichtig | Updates dauerhaft pausieren, nur Sicherheitspatches manuell | minimal |
Für die meisten Privatanwender lohnt sich der dauerhafte Bypass-Betrieb trotz gelegentlicher Update-Hänger immer noch mehr als ein vorzeitiger Hardware-Tausch – vorausgesetzt, die CPU unterstützt zumindest grundlegende Virtualisierungsfunktionen. Bei sehr alten Prozessoren ganz ohne diese Unterstützung wird der Aufwand mit jedem Funktionsupdate größer.
VBS und HVCI: Der Leistungseinbruch hinter den Kulissen
Virtualization-based Security ist seit Windows 11 standardmäßig zumindest in Form der Kernisolation aktiv. Auf CPUs mit nativer MBEC-Unterstützung kostet das kaum messbar Leistung. Unabhängige Benchmarks von ComputerBase zeigten dagegen bei aktivierter Speicherintegrität (HVCI) auf einer CPU ohne MBEC-Unterstützung Leistungseinbußen von teils über 20 Prozent in rechenintensiven Anwendungen und Spielen – ein Effekt, der mit aktiviertem RUM noch verstärkt wird.
Für die Update-Problematik bedeutet das: Ihr System arbeitet im Alltag bereits mit einem unsichtbaren Leistungsabzug – ein Abzug, der bei kurzen Vorgängen kaum auffällt, sich bei der zeitkritischen Finalisierungsphase eines Updates aber bemerkbar machen kann. Wer die Speicherintegrität (Core Isolation → Speicherintegrität in den Windows-Sicherheitseinstellungen) testweise deaktiviert, verliert zwar einen Teil der zusätzlichen Schutzschicht, gewinnt aber spürbar Leistung zurück – und reduziert nebenbei das Risiko künftiger Update-Timeouts.
Wer öfter mit Systemabstürzen oder Einfrieren zu kämpfen hat, findet ergänzende Lösungsansätze in unserem Artikel Windows 11 stürzt ab oder friert ständig ein – einige der dort beschriebenen Ursachen überschneiden sich mit der hier behandelten VBS-Problematik.
Ist es sicher, mit Bypass-Hardware weiter Updates zu installieren?
Ja, mit einer wichtigen Einschränkung: Sie installieren ein offizielles Microsoft-Produkt mit gültiger Lizenz, nur die Hardware-Konfiguration ist nicht offiziell supportet. Monatliche Sicherheitsupdates funktionieren in aller Regel normal. Größere Funktionsupdates wie der jährliche Versionswechsel sind die Updates, bei denen 0x800f0920 am häufigsten auftritt – genau hier braucht es im Zweifel die manuelle Nachhilfe aus diesem Artikel.
Microsoft weist in der offiziellen Dokumentation ausdrücklich darauf hin, dass bei Upgrades auf nicht unterstützter Hardware kein Anspruch auf technischen Support besteht. In der Praxis heißt das: Der reguläre Microsoft-Support hilft bei Bypass-Systemen nicht weiter – Community-Foren, Fachportale und genau diese Anleitung schon.
Häufige Fehler beim Bypass vermeiden
Ein paar typische Stolpersteine sorgen bei Bypass-Systemen zusätzlich für Ärger – unabhängig vom eigentlichen Update-Fehler.
- Veraltete Treiber: Gerade auf älterer Hardware bleiben Grafik- und Chipsatztreiber oft auf dem Stand der letzten unterstützten Windows-10-Version stehen. Ein Update über unseren Artikel Windows 11 Treiber aktualisieren reduziert Update-Konflikte spürbar.
- Vom Stick gebootet statt setup.exe ausgeführt: Wer beim In-Place-Upgrade versehentlich vom USB-Stick bootet, landet bei einer Neuinstallation statt eines Upgrades – alle Daten und Programme wären weg.
- Kein Backup vor dem Versuch: Jeder Eingriff in den Component Store birgt ein Restrisiko. Ein aktuelles Systemabbild ist Pflicht, kein optionaler Schritt.
- Falsche ISO-Architektur: x64- und ARM64-Pakete sind nicht austauschbar – ein häufiger Grund, warum die manuelle KB-Installation aus Methode 4 scheitert.
- Mehrere Bypass-Methoden gleichzeitig angewendet: Wer sowohl den Rufus-Bypass als auch den Registry-Schlüssel
AllowUpgradesWithUnsupportedTPMOrCPUgesetzt hat, riskiert widersprüchliche Kompatibilitätsflags im System – das kann bei künftigen Funktionsupdates zusätzliche Fehlercodes provozieren. Eine Methode reicht aus. - Update-Pause zu lange aktiviert: Wer Updates wegen wiederholter Fehlschläge für mehrere Monate pausiert, läuft Gefahr, mehrere kumulative Updates auf einmal nachholen zu müssen – das erhöht die Wahrscheinlichkeit für 0x800f0920 zusätzlich, weil die Installation dann entsprechend umfangreicher ausfällt.
Was hat sich 2026 geändert? Der KB5086672-Hotfix
Microsoft hat das Problem rund um beschädigte Update-Pakete inzwischen teilweise selbst adressiert: Der Hotfix KB5086672 behebt gezielt Fälle, in denen Geräte mit Windows 11 24H2 und 25H2 beim Installieren eines vorherigen Pakets den Fehler 0x80073712 anzeigten, weil Dateien fehlten oder beschädigt waren. Der Hotfix bringt keine neuen Funktionen, sondern stellt lediglich sicher, dass der ursprüngliche Updateinhalt korrekt nachinstalliert wird.
Für Bypass-Hardware ändert das wenig an der grundsätzlichen 0x800f0920-Problematik, ist aber ein gutes Beispiel dafür, wie dynamisch sich die Fehlerlandschaft bei Windows Update entwickelt. Prüfen Sie vor jedem erneuten Update-Versuch über Einstellungen → Windows Update → Updateverlauf, ob bereits ein passender Hotfix für Ihr Build verfügbar ist – das spart in manchen Fällen den kompletten manuellen Reparaturweg.
Fazit
Windows 11 Update Fehler 0x800f0920 ist auf Bypass-Hardware kein Zufall, sondern die logische Konsequenz aus fehlender nativer Sicherheitsbeschleunigung und einem hart codierten 15-Minuten-Zeitfenster. Die gute Nachricht: In den allermeisten Fällen lässt sich das Problem mit Bordmitteln lösen, ohne den Bypass-Weg komplett aufzugeben. Mein Rat aus der Praxis: Gehen Sie die sechs Methoden der Reihe nach durch, beginnend mit dem Cache-Reset – meistens ist die Lösung näher, als es der kryptische Fehlercode zunächst vermuten lässt. Sollten Sie regelmäßig mit Update-Problemen kämpfen, lohnt sich langfristig der Blick auf moderne, offiziell unterstützte Hardware – aber das eilt nicht, solange die hier gezeigten Methoden funktionieren.
Häufig gestellte Fragen
Ist der Fehler 0x800f0920 gefährlich für mein System?
Nein. 0x800f0920 löst in der Regel einen automatischen Rollback aus, der die Installation rückgängig macht und Ihr System auf den vorherigen, funktionsfähigen Stand zurücksetzt. Es entsteht dabei normalerweise kein Datenverlust.
Verliere ich Daten, wenn der Fehler 0x800f0920 auftritt?
In der Praxis nicht. Der Rollback-Mechanismus von Windows Update macht fehlgeschlagene Installationen automatisch rückgängig. Trotzdem sollten Sie vor jedem In-Place-Upgrade ein Systemabbild erstellen, da bei tieferen Eingriffen wie DISM-Reparaturen ein Restrisiko bestehen bleibt.
Was ist der Unterschied zwischen 0x800f0920 und 0x80073712?
0x800f0920 ist ein Timeout-Fehler des TrustedInstaller-Dienstes – die Installation reagiert innerhalb von 15 Minuten nicht. 0x80073712 bedeutet dagegen, dass im Windows-Komponentenspeicher (WinSxS) ein Manifest fehlt oder beschädigt ist. Beide treten gehäuft auf Bypass-Hardware auf, haben aber unterschiedliche technische Ursachen.
Bekomme ich auf Bypass-Hardware dauerhaft Updates?
Monatliche Sicherheitsupdates funktionieren auf den meisten Bypass-Systemen normal. Bei größeren Funktionsupdates kann es häufiger zu Abbrüchen wie 0x800f0920 kommen, die sich aber mit den in diesem Artikel beschriebenen Methoden in den meisten Fällen beheben lassen.
Zuletzt aktualisiert: Juni 2026 | Getestet auf: Windows 11 25H2, Juni 2026 | Autor: Vangelis | 25+ Jahre IT-Erfahrung | Gründer von windowspower.de seit 2003
