[English]Benutzer, die eine Insider Preview von Windows 11 oder eine Windows Server 2022 unter VMware Workstation installieren und virtualisiert betreiben möchten, laufen aktuell in ein Problem. Die Installation des Gast-Betriebssystems bricht mit einem Green Screen (oder Blue Screen) und der Fehlermeldung UNSUPPORTED_PROCESSOR ab. Ursache sind Modifikationen Microsofts für Hyper-V – aber es gibt Workarounds.
Anzeige
UNSUPPORTED_PROCESSOR-Fehler
Ich bin die Tage bereits bei den Kollegen von deskmodder.de auf das Problem gestoßen, welches von einem Nutzer berichtet wurde. Nachfolgende Tweets zeigen das Problem. Joseph Lee schreibt, dass der VMware Gast mit dem UNSUPPORTED_PROCESSOR Stopp-Code streikt, wenn beispielsweise Windows Server 2022 Build 20348.946 (KB5016693) installiert werden soll.
In obigem Tweet zeigt Xeno einen Blue Screen einer Produktiv-Version von Windows Server 2022. Aber es scheint auch mit Windows 11 Insider Preview-Builds zu passieren – die Kollegen von deskmodder.de haben einen entsprechenden Green-Screen gezeigt. Betroffen sind wohl Windows 11 25179 bzw. 25182 oder die Windows Server 2022 20348.946. Ursache sind Modifikationen Microsofts für Hyper-V, die mit VMware kollidieren. Der abgesicherte Modus von Windows scheint dieses Problem nicht zu triggern.
Workaround für UNSUPPORTED_PROCESSOR-Fehler
Xeno hat dann einen einfachen Workaround gefunden, indem die Datei ntoskrnl.exe aus der Build 25174 verwendet wird. Xeno vermutet, dass es an den neuen Kernel-Debugging-Funktionen liegt, die in der Build 25179 hinzugefügt wurden.
Anzeige
Die Kollegen von deskmodder.de beschreiben hier den Workaround etwas umfangreicher. Um Windows 11 oder Windows Server 2022 als Gast-Betriebssysteme in der virtuellen Maschine unter VMware Workstation installieren zu können, muss nachdem ersten Neustart die VM beendet werden. In den Optionen des Gastbetriebssystems ist dann unter CPU bspw. Number of processors und Numer of core per processors jeweils der Wert 1 einzustellen.
Dann sollte sich das Gastbetriebssystem installieren lassen. Problem ist aber laut deskmodder.de, dass zur Aktualisierung von Windows 11 Build 25179 auf die Build 25182 mindestens zwei Kerne erforderlich sind. Um aus dieser Baustelle heraus zu kommen, kann man die ntoskrnl.exe des Gasts mit folgenden Schritten ersetzen.
- Die Windows 11 Build 25174 als ISO-Datei holen, die ISO mit 7zip öffnen und im Ordner Source die install.wim öffnen
- Die Datei ntoskrnl.exe aus der in 7zip geöffneten install.wim an einen eigenen Speicherort kopieren
- Dann zur laufenden virtuellen Maschine mit Windows 11/Server 2022 wechseln und in den Ordner System32 gehen
- Dort die vorhandene ntoskrnl.exe in ntoskrnl.exe.old umbenennen (erfordert die Übernahme der Rechte) und anschließend die extrahierte ntoskrnl.exe in den Ordner hinein kopieren
Auf deskmodder heißt es noch, dass diese Lösung bis zum 15. September 2022 gültig bleibt – dann läuft die Windows 11-Signatur aus. Dürfte noch lustig werden mit der Virtualisierung von Windows 11 und Windows Server 2022. Mit Drittanbieter-Lösungen läuft man häufiger in Problemen und mit Hyper-V kann es einem passieren, dass ein Bug dessen Nutzung verhindert.
Anzeige
Das ist mir eher zu kompliziert. Da hoffe ich mal, dass Microsoft selbst eine Lösung für das Problem bereitstellt. Schließlich haben sie doch ein ureigenes Interesse an den kostenlosen Tests der W-Insider, die zweckmäßigerweise eine virtuelle Maschine nutzen!
Ich habe eine insider 25182.1000 auf meiner vmware workstation und die läuft ohne probleme
Meckert der Windows-Dateischutz (Windows File Protection, WFP) nicht, wenn man geschützte Systemdateien wie den Kernel austauscht und ersetzt veränderte Dateien dann automatisch wieder?
Frage ich mich auch. Wäre das nicht eine gigantische Sicherheitslücke in der supersicheren TPM Welt?
Nach heutigen Windows-Updates in einer Windows-2019-VM und einer Windows-10-VM unter VMware-Workstation 15.5.7, kommt jetzt ebenfalls der BlueScreen in den VMs. Workaround: Pozessoren und Kerne auf 1 setzen. Windows-Updates auf dem WIN10-Host-System wurden gestern installiert (KB5019959 & KB5020694).
Und nach der Installation der Updates lief das Guest-System wieder?
Ich kriege es leider nur noch mit 1/1 bei den Prozessoreinstellungen zum laufen.
Nein, die Installation der Windows-Updates in den VMs hat das Problem erst verursacht. Die Angabe der zuletzt installierten Windows-Updates auf dem Host-System war nur rein informativ. Nach der Installation dieser Updates auf dem Host, hatten die VMs noch gestartet. Mit der aktuellen VMware-Workstation 17.0 von gestern laufen beide VMs wieder mit mehreren Kernen. Scheint also so als ob das Problem seitens VMware gefixt werden kann, welches durch Microsoft verursacht wurde.
Das Problem ist bei uns aktuell auch auch bei der W10 Pro Edition aufgetaucht und VMware scheint das Problem nicht beheben zu wollen, obwohl sich die Version noch im Support-Zeitraum befindet.
https://communities.vmware.com/t5/VMware-Workstation-Pro/Windows-10-KB5019959-crashes-into-BSOD/m-p/2940794/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExBWDNOTDZGOTAxNjM5fDI5NDA3OTR8U1VCU0NSSVBUSU9OU3xoSw#M178838
Den Support von VMware zu erreichen ist übrigens ein Ding der Unmöglichkeit.
Man wird hier schon in der Bestelltung nur mit DoNotReply@vmware.com Adressen konfrontiert und auf der Webseite wird man im Kreis geschickt bzw. landet auf "not found" Seiten.
Ist man eingeloggt, kann man nicht einmal eine Anfrage für dieses Produkt hinschicken, man bekommt nur folgende Meldung:
"Mit dem ausgewählten Berechtigungskonto sind keine Produkte verknüpft. Wählen Sie ein anderes Berechtigungskonto aus, um Produkte anzuzeigen, für die ein Support-Anspruch besteht"