Forum Discussion
Windows 11 26H2: DISM 0x800f0915 und wiederkehrende PSFX-r-Payload-Meldungen
Guten Tag,
ich suche eine technisch begründete Reparaturmethode für wiederkehrende Meldungen im Windows-Komponentenspeicher. Mehrere DISM-Versuche haben den Befund reduziert, aber nicht vollständig behoben.
System und aktueller Befund
- Windows 11 Pro 26H2, x64, Deutsch, Build 26300.9711.
- DISM RestoreHealth endet mit 0x800f0915 / CBS_E_REPAIR_CONTENT_MISSING.
- Die letzte unabhängige Online-Prüfung mit ScanHealth meldet 82 CSI-Payload-Beanstandungen; vor dem letzten Reparaturversuch waren es 175.
- SFC /scannow meldet keine Integritätsverletzungen.
- Bisher ist kein konkretes Funktionsproblem nachgewiesen, das mit diesen Einträgen zusammenhängt.
- Alle 82 verbliebenen Einträge betreffen Pfade der Form Windows\WinSxS\<Komponente>\r\<Datei>. Sämtliche Ziel-Dateien sind vorhanden.
Bereits geprüft
- RestoreHealth mit Windows Update als Quelle.
- RestoreHealth mit lokaler deutscher Microsoft-Pro-ISO, einschließlich eines Versuchs unter LimitAccess.
- RestoreHealth mit lokaler Quelle und zugelassenem Windows Update.
- Eigene Reparatur-WIM aus dem Pro-Abbild der ISO 26300.9457, aktualisiert mit dem offiziellen, anhand der Prüfsumme verifizierten KB5127648 auf 26300.9711. Der tatsächliche Quellstand wurde anhand der Offline-Registry geprüft. Die WIM-Integritätsprüfung wurde erfolgreich durchlaufen.
- RestoreHealth mit dieser aktualisierten WIM, danach ein separater ScanHealth-Lauf und SFC.
Der letzte RestoreHealth-Lauf meldete 175 erkannte und 165 reparierte Beanstandungen, endete aber mit 0x800f0915. Der danach separat ausgeführte ScanHealth-Lauf meldete weiterhin 82. Die vorläufigen Reparaturzähler werden hier ausdrücklich nicht als Nachweis einer vollständigen Reparatur gewertet.
Längere Prüfungen liefen als unabhängige SYSTEM-Aufgaben über die Windows-Aufgabenplanung. Direkte erhöhte Aufrufe aus der verwendeten Automatisierungsumgebung hatten zusätzliche Probleme beim Laden von Registry-Hives; dieselben Test-Hives ließen sich über unabhängige SYSTEM-Aufgaben erfolgreich laden und entladen. Die beschriebenen letzten Reparatur- und Kontrollläufe verwendeten die funktionierende unabhängige Umgebung.
Dateivergleich und Referenzprüfungen
| Prüfung | Ergebnis |
|---|---|
| Existenz der 82 lokalen Restdateien | Alle vorhanden |
| Dieselben genauen Pfade in der aktualisierten Reparatur-WIM | 70 vorhanden, 12 dort nicht vorhanden |
| SHA-256-Vergleich dieser 70 Dateien | Alle 70 byteidentisch zwischen Quelle und Ziel |
| Schreibgeschützter Offline-Scan der aktualisierten WIM 26300.9711 | 93 CSI-Payload-Beanstandungen, keine CBS-/CSI-Metadatenkorruption |
| Schreibgeschützter Offline-Scan des unveränderten ursprünglichen ISO-Abbilds 26300.9457, Pro-Index 5 | 73 CSI-Payload-Beanstandungen, keine CBS-/CSI-Metadatenkorruption |
| Exakte beanstandete Komponentenpfade, die sich zwischen Originalabbild und lokalem Restbefund überschneiden | 50 |
Der Offline-Scan der Originalquelle wurde erfolgreich ausgeführt; seine Ausgabe lautet ebenfalls, dass der Komponentenspeicher repariert werden kann. Die Quelle wurde dabei nicht repariert oder verändert. Die temporären Abbild-Mounts wurden anschließend ausgehängt.
Beispiele lokaler Restmeldungen sind r\Globalization.adml, r\DeviceGuard.adml, r\NetTCPIP.dll, r\Microsoft.Web.WebView2.Core.dll und r\oobeerror-main.html, jeweils in ihren konkreten versionsgebundenen Komponentenverzeichnissen. Mehrere Dateien wurden als „Fixed“ gemeldet und beim anschließenden Scan erneut beanstandet.
Gleiche Dateihashes allein beweisen keine Fehlalarme: Ein Differenzpayload kann von seiner Basisversion und Rekonstruktionskette abhängen. Ich behaupte deshalb weder eine bestätigte Fehlklassifikation noch einen nachgewiesenen Microsoft-Produktfehler.
Meine Fragen
- Wie lässt sich bei diesem Befund nachweisen, ob PSFX-Reverse-Payloads tatsächlich ungültig sind oder ob ihre Validierung beziehungsweise Zuordnung zum Komponentenstand fehlschlägt?
- Welche zusätzlichen gezielten Diagnosen sind dafür erforderlich?
- Welche unterstützte Reparaturmethode oder nachweislich passende Quelle ist geeignet, wenn bereits das unveränderte Ausgangsabbild in der beschriebenen Prüfung beanstandet wird?
Apps und persönliche Dateien sollen erhalten bleiben. Ein zweites Betriebssystem, andere Partitionen und die Bootkonfiguration müssen unverändert bleiben. Ein ResetBase oder ein manuelles Überschreiben von WinSxS-Dateien wurde nicht vorgenommen.
Gezielte bereinigte Protokollauszüge, genaue Komponentenpfade und Prüfsummen können bereitgestellt werden. Die ursprünglichen vollständigen Protokolle werden wegen enthaltener lokaler Benutzerpfade nicht ungeprüft öffentlich veröffentlicht.
Vielen Dank für konkrete Hinweise, die über einen unveränderten erneuten RestoreHealth-Lauf hinausgehen.