Windows 11 24H2 -> Kumulatives Update KB5053656 (generell kumulative Updates) Update bei 100%, dann auf einmal Rollback (Fehler 0x800f0922

Hallo zusammen,

seit kurzem habe ich das Problem dass auf einer Windows 11 24H2 Installation das kumulative Update KB5053656 bei 100% plötzlich meldet „Es ist etwas schiefgegangen, die Änderungen werden rückgängig gemacht“, und dann ein Rollback auf die vorige Version macht.

Ich hab mir die C:\Windows\Logs\cbs.log Datei mal angesehen und da stand folgendes drin:


2025-04-01 18:17:34, Info                  CSI    0000139b Begin executing advanced installer phase 31 index 0 (sequence 0)
    Old component: (null)
    New component: (null)
    Install mode: delta
    Smart installer: true
    Installer ID: {c5f0e9d7-e844-4507-89e4-701b5a747221}
    Installer name: 'Boot File Servicing (BFSVC) Installer'
2025-04-01 18:17:34, Info                  CSI    0000139c BFSVC: 'ServiceBootFiles MuiOnly:n Res:n Fonts:n BootMgrOvw:n BootStatOvw:n DbgTrn:n SuspendBDE:n Offline:n'

2025-04-01 18:17:34, Info                  CSI    0000139d BFSVC: 'Failed to get partition name. Status = 0xc0000451'

2025-04-01 18:17:34, Info                  CSI    0000139e BFSVC: 'Failed to get system partition! Last Error = 0x3b92'

2025-04-01 18:17:34, Info                  CSI    0000139f BFSVC: 'ServicingBootFiles failed. Error = 0x3b92'

2025-04-01 18:17:34, Error                 CSI    000013a0@2025/4/1:16:17:34.985 (F) onecore\base\wcp\plugins\bfsvcai\bfsvcai.cpp(483): Error HRESULT_FROM_WIN32(15250) originated in function Windows::WCP::WCF::BfsvcInstaller::CommitChanges expression: Result
[gle=0x80004005]
2025-04-01 18:17:34, Info                  CONX   aepic: TRACE,PicRetrieveFileInfo,838,Deprecated flag used: [0x4000]

2025-04-01 18:17:34, Info                  CONX   aepic: TRACE,File::SetBaseFileInfoForPic,600,Retrieved "c:\windows\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.26100.3616_none_a50c1c1777611d54\tiworker.exe" info from cache

2025-04-01 18:17:34, Info                  CBS    Added CBS.log to WER report.
2025-04-01 18:17:34, Info                  CBS    Added CbsPersist_20250401161716.log to WER report.
2025-04-01 18:17:34, Info                  CBS    Added CbsPersist_20250401155826.cab to WER report.
2025-04-01 18:17:34, Info                  CBS    Added CbsPersist_20250312165040.cab to WER report.
2025-04-01 18:17:34, Info                  CBS    Added CbsPersist_20250312162829.cab to WER report.
2025-04-01 18:17:34, Info                  CBS    Added CbsPersist_20250312161730.cab to WER report.
2025-04-01 18:17:34, Info                  CBS    Added container.etl to WER report.
2025-04-01 18:17:34, Info                  CBS    Added Sessions.xml to WER report.
2025-04-01 18:17:34, Info                  CBS    Added pending.xml to WER report.
2025-04-01 18:17:35, Info                  CBS    Added poqexec.log to WER report.
2025-04-01 18:17:35, Info                  CBS    Added FilterList.log to WER report.
2025-04-01 18:17:35, Info                  CSI    000013a1@2025/4/1:16:17:35.288 CSI Advanced installer perf trace:
CSIPERF:AIDONE;{c5f0e9d7-e844-4507-89e4-701b5a747221};(null);334978us
2025-04-01 18:17:35, Info                  CSI    000013a2 End executing advanced installer (sequence 0)
    Completion status: HRESULT_FROM_WIN32(15250) 

2025-04-01 18:17:35, Error      [0x018049] CSI    000013a3 (F) Failed execution of queue item Installer: Boot File Servicing (BFSVC) Installer ({c5f0e9d7-e844-4507-89e4-701b5a747221}) with HRESULT HRESULT_FROM_WIN32(15250).  Failure will not be ignored: A rollback will be initiated after all the operations in the installer queue are completed; installer is reliable[gle=0x80004005]

Interessant waren hier die 2 Zeilen:

2025-04-01 18:17:34, Info                  CSI    0000139d BFSVC: 'Failed to get partition name. Status = 0xc0000451'

2025-04-01 18:17:34, Info                  CSI    0000139e BFSVC: 'Failed to get system partition! Last Error = 0x3b92'

Über Computerverwaltung->Datenträgerverwaltung habe ich dann gesehen dass 2(!) Systempartitionen existierten, und zwar 1. die EFI-Bootpartition (was korrekt ist), und die Cache-Partition (ext4).

Ich habe dann von der Windows 11 Installations-DVD eine Eingabeaufforderung gestartet und mittels DISKPART dann über den Befehl SETID den GUID-Partitionstyp der Cache-Partition auf 0FC63DAF-8483-4772-8E79-3D69D8477DE4 gesetzt, welches einer Linux-Partition entspricht. Anschliessend wieder Windows normal gestartet und das Update ist dann komplett durchgelaufen.

Offensichtlich kommt Windows mit mehr als einer Systempartition (bzw. als solche gekennzeichneten) nicht klar. Ich frage mich nur was die Cache-Partition als Systempartition markiert / gesetzt hat, weil in der Schulkonsole ist diese als ext4 gesetzt. Polt Windows da evtl. selbst dran rum?

Der Fehler ist mir früher schon unter Windows 10 untergekommen, wahrscheinlich ist die Lösung die gleiche.

Sorry, der Text ist ein wenig knapp. Bin gerade kurz angebunden, aber bei Fragen einfach schreiben. Wenn ich selbst neue Erkenntnisse habe werd ich Sie hier hinzufügen.

Greets

1 „Gefällt mir“

Hallo createc-solution,

vielen Dank für den Hinweis mit Lösung :slight_smile:

LG
Holger

So, hab die Windows 10 Installation auch noch geprüft, genau der gleiche Fehler im cbs.log.

Den Partitionstyp hab ich diesmal über gdisk in Linux geändert, ging einfacher.

Partition 5 (Cache) stand auf Type „EF00“ = EFI system Partition, wurde jetzt auf Typ „8300“ geändert.

Partitionstabelle vor der Änderung:

   1            2048          411647   200.0 MiB   EF00  EFI system partition
   2          411648          673791   128.0 MiB   0C01  Microsoft reserved ...
   3          673792       168445951   80.0 GiB    0700  Basic data partition
   4       168445952       252332031   40.0 GiB    8300  mint
   5       252332032       420104191   80.0 GiB    EF00  cache
   6       420104192       436881407   8.0 GiB     8200  swap
   

Partitionstabelle nach der Änderung:

   1            2048          411647   200.0 MiB   EF00  EFI system partition
   2          411648          673791   128.0 MiB   0C01  Microsoft reserved ...
   3          673792       168445951   80.0 GiB    0700  Basic data partition
   4       168445952       252332031   40.0 GiB    8300  mint
   5       252332032       420104191   80.0 GiB    8300  cache
   6       420104192       436881407   8.0 GiB     8200  swap

Hier auch noch 2 Screenshots aus der Sicht der Windows-Datenträgerverwaltung:

VOR der Änderung des Partitionstyps (Windows Update macht Rollback in dem Zustand):

NACH der Änderung des Partitionstyps (Windows Update läuft durch):

Also bei Windows 10 genauso vorgehen.

Bleibt nur die Frage warum der Partitionstyp der Cache-Partition irgendwann auf EF00 geändert wird, ich vermute fast dass LINBO dafür verantwortlich ist, weil da beim LINBO-Boot zuerst davon gebootet wird, kann ich aber nicht mit Sicherheit bestätigen.

Greets

Hallo,

das Gleiche (Cache-Partition ist vom Typ EFI) hab ich neulich auch mal festgestellt und ja, es wird durch LINBO verursacht. Es tritt dann auf, wenn auf der Cache-Partition das Bootable-Flag gesetzt ist. Das ist unglücklicherweise das Standardverhalten, wenn man über die Schulkonsole selbst ein Partitionsschema erstellt und dann eine Cache-Partition hinzufügt.

Nimmt man anschließend den Haken bei Bootable raus und läßt Linbo neu partitionieren ist der Partitionstyp Linux für die Cache-Partition wieder richtig.

VG
Thomas




Hier mal exemplarisch um die Herkunft des Problems zu illustrieren.

VG
Thomas

Hallo,

wir untersuchen ob linbo das macht.
Mich würde es wundern.
Ich hätte da eher das BIOS selbst im Verdacht: das vielelicht eine Logic drin hat, die meint:
„in einem efi System auf einer GPT Partitionierten Platte, müssen alle bootbar markierten Partitionen efi Partitionen sein“

Diese Aussage ist nicht gaz richtig, die Schlussfolgerung ist eben manchmal falsch.
Korrekt wäre:
„in einem efi System auf einer GPT Partitionierten Platte reicht es, wenn nur die efi Partition bootbar markiert sein“

LG
Holger

Hallo Holger,

stellen wir die Fragen anders:

1.) Wieso bzw. unter welchen Umständen braucht die Cache-Partition die Bootable-Flag?
2.) Warum wird die Bootable-Flag per Default gesetzt?

VG
Thomas

Hallo Thomas,

ich denke, das ist historisch so bedingt: weil es in einem biosbootenden System eben schon mal vor kam, dass mehrere Partitionen das bootflag besaßen.
Aber wir sind uns einig: es sollte in der start.conf Vorlage angepaßt werden.

LG
Holger

Moin!

Linbo setzt die Partitionseigenschaften nur beim Partitionieren. Danach setzt es nur noch den Dateisystemlabel falls angegeben. Das Bootflag wird auf Legacy-BIOS-Systemen bei Partitionen benötigt, von denen gebootet werden soll. Bei UEFI-System hat nur die EFI-Partition das Bootflag gesetzt.

VG, Thomas