Fehler 0x80070306 bei Juni-Update auf Windows Server 2025

[mwiederkehr 419]

Hallo zusammen

 

Auf einem Hyper-V laufen zwei VMs mit Windows Server 2025. Sowohl der Host als auch die VMs wurden mit der gleichen ISO installiert. Die Installation ist vor ein paar Wochen erfolgt. Das Mai-Update hat sich auf allen Systemen problemlos installieren lassen. Das Juni-Update bringt auf dem Host sowie einer VM den Fehler 0x80070306. Auf einer VM hat es funktioniert.

 

Nach einem Update-Versuch zeigt "DISM.exe /Online /Cleanup-Image /CheckHealth" einen beschädigten Komponentenspeicher. Dieser lässt sich mit "DISM.exe /Online /Cleanup-Image /RestoreHealth" reparieren. "DISM.exe /Online /Cleanup-Image /StartComponentCleanup" ist ebenfalls erfolgreich durchgelaufen. Dies auch mit Angabe der install.wim von der ISO.

 

Im Anhang einige, hoffentlich relevante, Zeilen aus der CBS.log.

 

Was könnte das Problem sein? Eine beschädigte ISO sollte ausgeschlossen sein, da das Update in einer VM funktioniert hat. Und noch wichtiger: Was sind mögliche Lösungen?

 

Besten Dank!

cbc_log.txt

[MurdocX 1.062]

Hi,

 

ich habe nichts erkennen können. Habe die Datei aber mal in die Ki gehauen. Das ist die Antwort. Vermutlich hast du den Lösungsweg auch schon probiert. Hier mal das Ergebnis.

 

Zitat

Kurzdiagnose: Component-Store-Korruption (WinSxS). Die Servicing-Engine kann mehrere Dateien nicht „hydrieren" – also aus Basis-Komponente + Delta rekonstruieren –, weil mindestens ein Basis-Payload im Store fehlt bzw. inkonsistent ist. Die abschließenden 0x80070306 (ERROR_ERRORS_ENCOUNTERED) sind nur der Sammel-Rollup, nicht die eigentliche Ursache.

Was das Log konkret sagt:

• DeltaDecompressBuffer / ApplyDeltaGetReverseB mit Win32 774 → das Anwenden bzw. Erzeugen eines Reverse-Deltas scheitert. Das ist die Delta-Engine, die einen Volltext aus Basis + Patch nicht zusammenbauen kann.
• Der Schlüssel ist diese Zeile: Component directory missing. Dir: ...amd64_microsoft-windows-ccffilter_...26100.1150_none_... → das Basis-Verzeichnis, gegen das das Delta laufen müsste, ist schlicht weg.
• IntegrityState Valid: true und RetrievedChecksum == ComputedChecksum → der abgerufene Blob ist auf Disk intakt. Das Problem ist nicht eine bitfaule Delta-Datei, sondern die fehlende/unvollständige Basis, gegen die appliziert wird.
• FileHasForwardReverseDeltas = false, GenerateReverseDelta = true → das System will zur Laufzeit ein Reverse-Delta erzeugen (für spätere Deinstallierbarkeit), braucht dafür aber die RTM-Basis (...26100.1), die nicht sauber vorliegt.
• ...CCFFilter... does not have a winner but has 4 other component version(s) → mehrere Versionen im Store, aber keine aufgelöste „Gewinner"-Version. Klassisches Zeichen für einen inkonsistenten Store.

Betroffen sind zwei unabhängige Komponenten (BgpNCProvider/SDN-Netzwerkcontroller und CCFFilter/Filtertreiber). Dass es nicht nur eine trifft, spricht für eine store-weite Inkonsistenz, nicht für ein einzelnes defektes Paket.

Wahrscheinliche Auslöser (nach Plausibilität):

• Abgebrochenes vorheriges Update – Reboot/Stromverlust während des Servicing, oder ein CU-Rollback hat den Store halb hinterlassen.
• Aggressives vorheriges Cleanup, speziell DISM ... /StartComponentCleanup /ResetBase. ResetBase entfernt superseded Payloads; braucht später ein Vorgang genau diese Basis, kommt exakt „Component directory missing".
• Disk-/Dateisystemfehler oder ein AV-/Backup-Filtertreiber, der WinSxS während des Updates angefasst hat.

Vorgehen (server-tauglich, von schonend nach hart):

1. Erst messen:

   DISM /Online /Cleanup-Image /ScanHealth
   

   Details in C:\Windows\Logs\CBS\CBS.log und C:\Windows\Logs\DISM\dism.log.

2. Reparieren – mit expliziter Quelle, weil der Online-Store selbst das Defekte ist und reine WU-Reparatur hier oft nicht greift:

   DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:<Index> /LimitAccess
   

   Kritisch: Die WIM/ESD muss zum exakt gleichen Build passen (26100, gleiches Server-2025-Release). Index vorher mit DISM /Get-WimInfo /WimFile:D:\sources\install.wim prüfen. Bei Build-Mismatch findet DISM die Basis nicht und scheitert erneut.

3. Danach sfc /scannow und das ursprünglich fehlgeschlagene Update wiederholen.

4. Wenn RestoreHealth den Store nicht sauber bekommt – bei „directory missing" gar nicht selten –: In-Place-Upgrade / Repair-Install (ISO mounten, setup.exe, „Dateien und Apps behalten"). Das baut den Component Store komplett neu auf und ist auf Servern erfahrungsgemäß der zuverlässigste Weg bei struktureller Store-Beschädigung. Vorher Snapshot/Backup.

Als paralleler Sanity-Check bei Verdacht auf Volume-Ebene: chkdsk aufs Systemvolume (Offline-Pass beim nächsten Reboot, auf Prod disruptiv).

Noch ein Punkt: Der Log ist vom 12.06., also frisch. Falls das an einen bestimmten Juni-CU gekoppelt ist, kann ich gezielt prüfen, ob dazu ein bekanntes Issue dokumentiert ist – sag Bescheid, dann suche ich nach dem konkreten Build.

 

[testperson 2.007]

Hi,

 

"wie immer", falls die VM nicht die exotischste Anwendung bereitstellt: Neue VM installieren und Workload migrieren als Option?

 

Falls die Anwendung(en) / Rolle(n) auf dem Server das unterstützen, ggfs. die VM einmal exportieren, importieren und Netzwerk disconnecten und dann per Sysprep generalisieren. Im Anschluss dann nochmal versuchen das Update zu installieren.

 

Ansonsten könntest du auch bei Sysnative vorbeischauen und dort einen Thread eröffnen: https://www.sysnative.com/forums/forums/windows-update.88/ (Ich habe deren Service allerdings noch nie genutzt und es gehört wohl ein wenig Vertrauen dazu, deren Fixe einzuspielen. Aber auch das könnte man ggfs. in einem Klon der original VM zumindest testen.)

 

HTH

Jan

[mwiederkehr 419]

Hallo zusammen

 

Danke für eure Antworten. Die Schritte, welche die KI erwähnt hat, habe ich durchgeführt. Bis auf die Reparaturinstallation.

 

Ich kann mir nicht erklären, weshalb der Host und eine VM (nicht aber die zweite VM) betroffen sind. Auf dem Host ist nur die Hyper-V-Rolle aktiviert. Da sonst alles läuft und es ein Markenserver ist, gehe ich nicht von einem Problem mit dem Speicher aus.

 

Sysnative sieht interessant aus. Dass die Fixes für einzelne Systeme machen, erstaunt mich. Das sollte eigentlich Microsoft anbieten.

 

LG Manuel

[daabm 1.474]

@mwiederkehr ich würd mir da nicht zu viele Gedanken machen. Wir haben das auch regelmäßig. "Eigentlich" sind alle Server gleich, aber immer wieder verhackstückt sich einer CBS. Da muss man gut überlegen, ob sich aufwändige Reparaturversuche lohnen oder ein Redeploy die bessere Wahl ist.