Updates, die auf einem einzelnen Rechner partout nicht durchlaufen, kosten Admins regelmäßig einen halben Tag. Der Fehlercode 0x80070005 ist dabei ein Sonderfall: Er bedeutet „Zugriff verweigert“ (E_ACCESSDENIED) und zeigt kein beschädigtes Paket an, sondern fehlende Datei- oder Registrierungsrechte. Microsoft dokumentiert den Fehler für Windows-Client, Windows Server und Azure-VMs gleichermaßen.
Was der Fehler bedeutet
0x80070005 ist kein update-spezifischer Code, sondern der allgemeine Windows-Fehler für verweigerte Zugriffe. Beim Update scheitert entweder der Dienst „Windows Update“ oder das CBS-Modul (Component Based Servicing), weil es eine Datei im Komponentenspeicher nicht anlegen oder einen Registrierungswert nicht schreiben darf.
Oft scheitern nur kumulative Updates, während andere Installationen weiterlaufen. Wer nur den Cache löscht, verliert Zeit: Ohne Reparatur der Rechte kommt der Fehler beim nächsten Patchday zurück.
Fünf Ursachen, die Microsoft nennt
1. Fehlende Rechte im Komponentenspeicher
Das Dienstkonto von TrustedInstaller hat keine Berechtigung mehr für den Ordner %windir%\WinSxS oder für %windir%\SoftwareDistribution. Ursache sind meist kopierte Profile, Restores aus Images oder halb abgebrochene Reparaturversuche.
2. Registrierungsrechte am CBS-Schlüssel
Die ACL des Unterschlüssels HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing passt nicht mehr zur Standardkonfiguration. Auch das ist häufig ein Erbe von Hardening-Skripten.
3. Sicherheitstools und Filtertreiber
Antivirus-, EDR- oder Backup-Agenten halten Dateien im Update-Pfad gesperrt. Solche Sperren sieht man nicht im Update-Log, sondern nur über die Filtertreiber-Liste.
4. SYSTEM ohne Vollzugriff auf %windir%
Wird dem SYSTEM-Konto der Vollzugriff auf C:\Windows entzogen, scheitert praktisch jedes Update. Diesen Zustand erzeugen geliehene Härtungs-Baselines erstaunlich oft.
5. Gruppenrichtlinie oder Management-Agent
Eine GPO-Einstellung oder ein Agentschutz verhindert Schreibzugriff auf Systemverzeichnisse. Vor der Reparatur lohnt deshalb ein Blick in gpresult /h auf Einträge zur Dateisystem-Sicherheit.
Diagnose: erst loggen, dann reparieren
Der Fehlercode allein sagt nicht, welche Datei betroffen ist. Die CBS.log nennt den konkreten Pfad, oft als „Failed to create file“ oder „Failed to internally open package“ mit HRESULT 0x80070005.
Select-String -Path "$env:windir\Logs\CBS\CBS.log" -Pattern "0x80070005" |
Select-Object -Last 20Für das Windows-Update-Log erzeugt PowerShell eine statische Kopie, die sich gefahrlos durchsuchen lässt:
Get-WindowsUpdateLog -LogPath C:\Temp\WU.logZusätzlich lohnt der Blick auf die ACLs. Besitzer des Komponentenspeichers muss NT SERVICE\TrustedInstaller sein:
$acl = Get-Acl "$env:windir\WinSxS"
$acl.Owner
$acl.Access | Where-Object { $_.IdentityReference -match 'TrustedInstaller|SYSTEM' } |
Format-Table IdentityReference, FileSystemRights, AccessControlTypeLösung in fünf Schritten
Schritt 1: ACLs am Komponentenspeicher zurücksetzen
In einer Eingabeaufforderung mit Administratorrechten werden die Standardrechte wiederhergestellt. Der Lauf über den gesamten WinSxS-Baum dauert je nach Datenträger 10 bis 30 Minuten — vorher Snapshot oder Image-Backup ziehen.
icacls "%windir%\WinSxS" /reset /t /c /q
icacls "%windir%\SoftwareDistribution" /reset /t /c /qSchritt 2: Besitz auf TrustedInstaller zurücksetzen
Bleibt der Fehler, wird der Besitzer des Komponentenspeichers explizit gesetzt. Danach neu starten und das Update erneut anstoßen.
icacls "%windir%\WinSxS" /setowner "NT SERVICE\TrustedInstaller" /t /c /qSchritt 3: Update-Komponenten zurücksetzen
Dieser Schritt löst verklemmte Zustände im Update-Agent. Die Dienste werden gestoppt, die Cache-Ordner umbenannt und die Dienste wieder gestartet; die alten Ordner bleiben als Sicherheitsnetz liegen.
net stop wuauserv
net stop bits
net stop cryptSvc
ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren %windir%\System32\catroot2 catroot2.old
net start cryptSvc
net start bits
net start wuauservSchritt 4: Komponentenspeicher reparieren
DISM prüft den Store gegen die Reparaturquelle, anschließend kontrolliert sfc die Systemdateien. Beide Läufe brauchen Zeit und sollten nicht parallel gestartet werden.
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannowSchritt 5: Fremde Filtertreiber prüfen
Die Liste zeigt alle Dateisystemfilter. Nicht-Microsoft-Treiber lassen sich testweise entladen; das ist der schnellste Weg, einen blockierenden EDR- oder Backup-Agenten zu identifizieren.
fltmc
fltmc unload <DriverName>Was im Firmennetz zusätzlich zählt
Rechte-Abweichungen flächig finden
Tritt der Fehler auf mehreren Clients auf, war es fast nie Zufall, sondern eine GPO oder ein Image. Eine WinRM-Abfrage über alle betroffenen Rechner zeigt die Abweichler in einem Lauf:
Invoke-Command -ComputerName (Get-Content .\clients.txt) -ScriptBlock {
[pscustomobject]@{ Host = $env:COMPUTERNAME; Owner = (Get-Acl "$env:windir\WinSxS").Owner }
} | Format-Table -AutoSizeHärtung dokumentieren statt still überschreiben
icacls /reset stellt Microsofts Standard wieder her und entfernt damit bewusst gesetzte Härtung. Wer WinSxS-ACLs per Baseline anfasst, sollte die Abweichung dokumentieren — sonst repariert der nächste Patchday gegen die eigene Vorgabe.
Fazit
0x80070005 ist ein Rechteproblem, kein Update-Problem. Wer zuerst CBS.log und ACLs prüft, repariert gezielt statt auf Verdacht zu resetten. In Domänenumgebungen gehört danach die Frage geklärt, welche GPO oder welches Image die Rechte verbogen hat. Ein Inplace-Upgrade setzt die ACLs ebenfalls neu, ist aber der letzte Schritt — bei Servern mit Drittanbieter-Software ist die Reparatur per icacls und DISM risikoärmer.
Quellen
Microsoft Learn: Problembehandlung bei Windows Update Fehler 0x80070005 (abgerufen am 02.11.2026)
Microsoft Learn: Repair a Windows Image (DISM) (abgerufen am 02.11.2026)
Microsoft Learn: Windows Update log files (abgerufen am 02.11.2026)
Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.
No responses yet