Hallo,

auch bei mir hat das set id geholfen. Wir hatten auf dem PC schon länger, dass Updates nicht abgeschlossen wurden. Das wurde vom Nutzer ein paar Monate hingenommen - einfach nicht neu starten. Das nächste Update wird schon laufen - Dann kam es aber ganz dicke und beim Neustart nach Update gabs einen Bluescreen und es ging gar nichts mehr.
File: \WINDOWS\System32\drivers\vmbus.sys
Error code:0xc0000098

Auch Recovery nicht mehr möglich. Das bringt einen dann noch Fehler im BCD vor die Nase.

Behebung: mit z.B. Macrium Reflect eine alte vmbus.sys in den drivers Ordner kopieren - System fährt wieder hoch und spult das Update zurück. Dann unter Windows mit Diskpart das ESP Laufwerk mit set id bearbeiten wie bereits beschrieben. Danach laufen auch die Updates wieder rund.

Es musste wirklich eine alte vmbus.sys von Jahresanfang oder älter sein. Ein aktuelles ISO konnte nicht herhalten.

Hallo zusammen,

hatte das gleiche Problem, habe MBR auf GPT konvertiert.

Das hat mein Problem behoben:
Sobald der Datenträger von MBR auf GPT konvertiert wurde, im diskpart für die Systempartition die passende ID setzen:

set id="C12A7328-F81F-11D2-BA4B-00A0C93EC93B"
gpt attributes=0x8000000000000000

als kleinen zusatz
man kann mit
detail parition

prüfen was aktuell gesetzt ist.

Grüße
Dieter S.

Vielen lieben Dank auch an DK2000!!! :dafür:

Ich hatte Monate lang ein ähnliches Problem, dass keine Updates mehr installiert wurden (nach mehreren Neustarts und 90 % "Updates konnte nicht abgeschlossen werden. Änderungen werden rückgängig gemacht.") und mit selber Fehlermeldung beim Inplace Update ("Es konnte nicht ermittelt werden, ob Windows 10 auf Ihrem Computer ausgeführt werden kann. Beenden Sie Setup und wiederholen Sie den Vorgang."). Ich bin fast wahnsinnig geworden.

Meine Festplatte war die ganze Zeit GPT und Windows wurde auch als UEFI installiert. Umso seltsamer schien es, dass da nun plötzlich ein Problem vorlag.

Das hat mein Problem behoben:
[quote]
Sobald der Datenträger von MBR auf GPT konvertiert wurde, im diskpart für die Systempartition die passende ID setzen:

set id="C12A7328-F81F-11D2-BA4B-00A0C93EC93B"
gpt attributes=0x8000000000000000
[/quote]
:daumen:

Ich habe einfach mit diskpart die ID und Attributes der Systempartition überschrieben und schon ließen sich sowohl die Updates auf normalem Weg installieren und auch das Inplace Update lief problemlos durch.
Ohne diesen Thread und den Tipp wäre ich niemals darauf gekommen, dass das das Problem sein könnte. Auch Microsoft konnte mit sämlichen Boardmitteln das Problem nicht beheben geschweige denn überhaupt benennen.
1000 Dank nochmals!!!
:dankeschoen:

Na, das ist doch schön, das es jetzt geklappt hat. Ja, das Windows Setup im Upgrade-Modus ist da teilweise sehr pingelig. Selbst wenn Windows im UEFI-Modus mit GPT installiert ist und die ID der ESP nicht passt, aus welchen Gründen auch immer, dann spring es auch mit dem Fehler raus.

Aber warum das jetzt bei Dir so ein "Mixed-Mode" war, das bleibt offen.

Ja, das Upgrade ist durch.
Vielen dank nochmal, auch für die Erklärung zum Schluß.

Ict echt nicht selbst verständlich, hab ich schon ganz anders erlebt. Leider.

Gut, warum [i]bcdboot [/i]jetzt nicht gefunden wurde, kann ich nicht sagen. Der soll eigentlich aus dem Ordner [i]C:\Windows\Boot[/i] entsprechend der Angabe BIOS oder UEFI die passenden Dateien in die Systempartition schreiben. Aber gut, hast einen anderen Weg gefunden.

Und da UEFI keine Code in irgendwelchen Bootsektoren verwendet, sicherheitshalber mittels [i]bootsect[/i] neu schreiben lassen (MBR und in C:\) und die Systempartition muss für BIOS-Mode aktiv sein.

Gut, aber hat ja jetzt alles geklappt. Dann sollet das Upgrade jetzt zufrieden sein und durchlaufen.

----

Sobald der Datenträger von MBR auf GPT konvertiert wurde, im [i]diskpart[/i] für die Systempartition die passende ID setzen:

[i]set id="C12A7328-F81F-11D2-BA4B-00A0C93EC93B"
gpt attributes=0x8000000000000000[/i]

Das Attribute [i]0x8000000000000000[/i] gibt an, dass die Partition nicht automatisch einen Laufwerksbuchstaben erhält.

Weiß jetzt nicht, ob das automatisch geschieden. Aber das ist die ID und Attribute für die ESP, so wie das Windows Setup das erstellt. Dann wird die von Windows und dem Upgrade auch als solche erkannt. Mindestgröße ist derzeit 100MB und Dateisystem sie Windows FAT32 vor.

So, Rückmeldung.

Der Befehl [b]bcdboot C:\Windows /f BIOS[/b] hat nicht funktioniert, er wurde nicht erkannt.
Es kam nur ich solle Help eingeben um mir die syntax anzeigen zu lassen.

Deshalb bin ich einen anderen Weg gegangen.
Ich habe auf der Systempartition den Ordner EFI gelöscht.
Von einem anderen Windows 10 habe ich die nötigen Dateien kopiert:

Boot
bootmgr
BootNXT
Bootsec.BAK

Dann mittels Bootice einen neuen BCD im Ordner Boot angelegt.

Neu gestartet... funktioniert nicht. No Boot Device.

Dann habe ich mit Ventoy gestartet und dort im Menu F4 Local Boot ausgewählt:
Suche und starte Windows -> was soll ich sagen, das lokale Windows wurde gestartet.

Im gestarteten Windows hab ich dann mit [i]msinfo32.exe[/i] die Zeile "BIOS-Modus" anzeigen lassen. Es steht nun Vorgängerversion drin. Das ist ja schon mal nicht schlecht. Doch warum staretet es dann nicht von allein?

Noch mal alles mit Bootice den BCD überprüft. War alles korrekt.
Dann noch mittels BootIce über PartManage die Systempartition kontrolliert und auf Active gesetzt.

Noch schnell den von Dir genannten Befehl ausgeführt: bootsect /nt60 ALL /mbr

Und was soll ich sagen... ich bin grad dabei das Inplace Upgrade zu machen.
Jetzt muß es nur noch durchlaufen :daumen:

Ich verneige mich vor Deiner Weiheit :knienieder:
Vielen vielen Dank. Ohne Dich hätte ich das nicht geschafft :dankeschoen:

[quote]Alternativ die Platte nach GPT konvertieren und aus der System-Partition eine EFI-Systempartition machen.[/quote]
Kannst Du mir sagen wie man aus einer System_Partition eine EFI-Systempartition macht?

Ok. Versuch ich mal.
Ich hab zum Glück ein aktuelles Backup.

Meld mich dann.
Vielen dank für Deine Hilfe bis hier hin :-)

Gut, das erklärt es. Das System läuft im UEFI-Modus, der Datenträger ist aber für BIOS-Modus ausgelegt. Das irritiert das Setup und springt raus. In wie Weit Ventoy schuld ist, kann ich nicht sagen. Aber kann schon sein, dass hier UEFI Bedingt etwas nicht geklappt hat.

Gut, hast Du ein Backup vom System, falls jetzt gleich etwas schief geht? Falls ja:

bcdboot C:\Windows /f BIOS
bootsect /nt60 ALL /mbr

Über Diskpart die Systempartition als "Aktiv" markieren.
Im UEFI überprüfen, ob CSM aktiv ist, die Platte als Primär eingetragen ist und das System im BIOS Mode lädt.
So könnte es klappen.

Alternativ die Platte nach GPT konvertieren und aus der System-Partition eine EFI-Systempartition machen.

Und ja, die Einschränkung BIOS/MBR und UEFI/GPT ist nur eine Einschränkung von Windows-Setup. Dem UEFI selber ist das vollkommen Latte, ob der Datenträger GPT oder MBR ist. Für das moderne UEFI zählt nur, dass es eine Partition mit der [i]\EFI\Boot\bootx64.efi[/i] findet. Teilweise ist es sogar schon egal, ob die ESP mit FAT32 oder NTFS formatiert ist. Und sobald die bootx64.efi gestartet wurde, ist es Windows selber auch erst einmal egal, ob MBR oder GPT. Erst das Upgrade macht dann wieder Probleme.

Und im Grunde genommen ist es bei moderner Hardware egal, ob BIOS/MBR oder UEFI/GPT. Das macht da keinen Unterschied mehr. Wenn möglich, installiere ich nur noch in UEFI/GPT.

EFI
    |-Boot
           |-bootx64.efi
    |-Microsoft
          |-Boot
                |-BCD
          |-Recovery

Ich hab mir die systempartition anzeigen lassen und dann per Bootice den BCD geöffnet.
Hier steht als bootfile: \windows\system32\winload.efi

Die Struktur selber in der Partition sieht mir auch nach UEFI aus

[code]EFI
|-Boot
|-bootx64.efi
|-Microsoft
|-Boot
|-BCD
|-Recovery[/code]
Aber wie kann die Festplatte dann MBR sein?

Komischerweise steht das UEFI.
[attachment=0]BIOS-Modus.jpg[/attachment]

Zur Erklärung:
Ich habe einen Installationsstick mit Ventoy gemacht.
Den starte ich CMS und installiere dann Windows.
Das hab ich so bei ca. 10 Rechnern schon gemacht.

Das hier ist der einzigste Rechner wo dieser Unsinn passiert.

Wenn ich in der CMD bcdedit eingebe steht folgendes:
C:\windows\system32>bcdedit
Der Speicher für die Startkonfigurationsdaten konnte nicht geöffnet werden.
Das angeforderte Systemgerät kann nicht gefunden werden.

Das Setup scheint da anderer Ansicht zu sein. Was sagt denn [i]msinfo32.exe[/i] in der Zeile "BIOS-Modus" dazu?

Oder [i]bcdedit[/i]? Wird dort die [i]Winload.exe[/i] oder [i]Winload.efi[/i] gestartet?

Ich installiere immer im BIOS/MBR Modus.
Der Disktyp ist MBR:
[attachment=0]MiniTool Partition Wizard.jpg[/attachment]

Firmware type: UEFI

2021-05-18 09:47:45, Error                 CONX   CHostIsUEFICompliantChecker failed. [Failed to check whether host has UEFI disk layout.] HRESULT = 0x80070003

Ist das Problem mit den Partitionen, hier Systempartition:

[code]Firmware type: UEFI

2021-05-18 09:47:45, Error CONX CHostIsUEFICompliantChecker failed. [Failed to check whether host has UEFI disk layout.] HRESULT = 0x80070003[/code]

Dem passt da die Partitionierung nicht.

Ist das System im UEFI Modus oder BIOS Modus installiert?
Ist die Platte mit GPT oder MBR partitioniert?

Das Upgrade akzeptiert nur UEFI/GPT oder BIOS/MBR.

Irgendwo ist das bei Dir nicht eindeutig.

Hallo,

danke für die schnelle Antwort.

[attachment=3]setupact.log[/attachment]
[attachment=0]setupdiagresults.xml[/attachment]
[attachment=1]diskpart.jpg[/attachment]
[attachment=2]Datenträgerverwaltung.jpg[/attachment]