Problem mit Gast-System Win 10 32 Bit

[UpdateFetischist]

Liebe Community,

so langsam bin ich wirklich am Verzweifeln. Ich habe seit geraumer Zeit das Problem, dass Gast-Systeme mit Windows 10, 32 Bit (und nur 32 Bit!) beim Durchführen der Windows-Updates abstürzen. Dafür muss es doch eine Lösung geben.

Zuerst ist das Problem in folgender Konstellation aufgetreten:
Host-System: Win 10 Enterprise, Version 21H2, 64 Bit
Gast-System: Win 10 Pro, Version 21H2, 32 Bit
VMware Workstation Player 16.2.4

Bis zum September-Patchday 2022 funktionierte alles problemlos. Mit den Oktober-Patches trat das Problem erstmalig auf und ist seitdem präsent. Das Problem wird immer durch das kumulative Update ausgelöst und äußert sich folgendermaßen. Alle Updates werden heruntergeladen und installiert. Der anschließende Neustart läuft zunächst normal. Die Fortschrittsanzeige läuft bis 30%, dann erfolgt der eigentliche Neustart des virtuellen PCs. Es erscheint kurz das hellblaue Windows-10-Logo und anschließend folgt der BSOD ("SYSTEM THREAD EXCEPTION NOT HANDLED"), dann ein zweiter Neutart wieder mit BSOD, aber anderer Fehlermeldung ("DRIVER IRQL NOT LESS OR EQUAL", "Fehlerursache: pci.sys") und dann startet die automatische Reparatur und die Updates werden rückgängig gemacht. Danach startet die VM wieder normal, aber eben mit Patch-Stand September 2022. Ich habe auch schon das aktuelle kumulative Update aus Microsofts Update-Katalog heruntergeladen und „von Hand“ installiert, mit dem gleichen Ergebnis. Und auch die aktuellen VMware-Tools ändern nichts daran.

Ich konnte das inzwischen auf 4 verschiedenen Rechnern in unterschiedlichen Konstellationen nachvollziehen.

Getestete Host-Systeme:
Win 10 Enterprise, Version 21H2, 64 Bit
Win 10 Enterprise, Version 22H2, 64 Bit
Win 10 Pro, Version 21H2, 64 Bit
Win 10 Pro, Version 21H2, 64 Bit

Getestete Gast-Systeme:
Win 10 Pro, Version 21H2, 32 Bit
Win 10 Pro, Version 22H2, 32 Bit
Win 10 Enterprise Evaluation, Version 22H2, 32 Bit

Getestete Vmware-Workstation-Versionen:
Player 16.2.4
Player 16.2.5
Player 17.0.0
Player 17.0.1
Pro 17.0.1 (30-Tage-Testversion)

Ich habe es gerade heute nochmal versucht. Mit dem aktuellen Workstation Pro eine neue VM erstellt, in dieser mit der aktuell bei Microsoft erhältlichen ISO Win 10 Enterprise Evaluation, Version 22H2, 32 Bit (die ISO hat den September-2022-Patchlevel) installiert, ohne andere Software-Installationen oder Änderung von Einstellungen. Anschließend einfach nur Windows Update laufen lassen und der Neustart endet wieder mit BSOD.

Mit einem 64-Bit-Windows als Gast-System habe ich dieses Problem übrigens nicht. Ich kann mir auch nicht vorstellen, dass ich der einzige bin, der dieses Problem hat. Tipps, die ich dazu bisher gelesen habe (u. a. im offiziellen VMware-Forum), haben nicht gefruchtet. Manche sagen, dass Problem wäre mit Version 16.2.5 bzw. 17.0.0 gelöst worden. Bei anderen soll es geholfen haben, die Anzahl der CPU-Kerne für die VM auf 1 zu reduzieren. Bei mir hilft dass alles nicht.

Hat dazu irgendjemand eine Idee oder Lösung?

[~thc]

Kann ich genau so bestätigen (Host Win11 22H2 x64; Gast Win10 22H2 x86; Player 17.0.1).
Bei mir sind es zwei gleiche BSODs (2 x THREAD EXCEPTION) vor der Reparatur.

[Dayworker]

Der Hinweis "DRIVER IRQL NOT LESS OR EQUAL", "Fehlerursache: pci.sys" deutet auf ein DLL-Problem hin. Seit einiger Zeit rollt Winzigweich auch die VMware-Tools über die M$-Updates aus. Auf der anderen Seite trommelt M$ schon seit längerem nur noch für die 64bit Ausführungen seiner offiziell supporteten Betriebssysteme. Es ist also gut möglich, daß sich eine DLL in der falschen Bitbreite oder ein anders gelagertes Problem eingeschlichen hat. Zu letzterem paßt dann wiederum, daß M$ bei Win11 mit dem ersten Refresh erneut an der Optik gefeilt, aber kaum seit Jahren mitgeschleppte Bugs beseitigt hat.

Schaut mal bei Windows 10 22H2, KB5016616, KB5017308, KB5017380, KB5018410, KB5019959, KB5021233 hang on reboot after install vorbei, ob sich das Problem damit lösen läßt.

[UpdateFetischist]

Schaut mal bei Windows 10 22H2, KB5016616, KB5017308, KB5017380, KB5018410, KB5019959, KB5021233 hang on reboot after install vorbei, ob sich das Problem damit lösen läßt.

Die dort beschriebene Anleitung konnte ich zwar genauso nachvollziehen, aber mein Problem ließ sich damit leider nicht lösen...

[Dayworker]

Kannst du mal testweise den Plattencontroller auf SCSI umstellen, wie im VMTN unter SYSTEM THREAD EXCEPTION NOT HANDLED beschrieben.

Kommt ihr noch in den Abgesicherten Modus rein und könnt im Win-Ereignis-Log nach dem fehlerhaften Treiber suchen?

Gibt es in der VMX-Datei einen Eintrag mit:

Code: Alles auswählen

hpet0.present = "TRUE"

[~thc]

Das Umstellen des Festplattencontrollers auf "SCSI" (LSI SAS) löst das Problem.
Es scheint also mit dem virtuellen NVMe-Controller zusammenzuhängen.

[UpdateFetischist]

Klingt vielversprechend. Bin aber gerade unterwegs und kann das erst nächste Woche testen. Melde mich dann nochmal.

[UpdateFetischist]

Das Umstellen des Festplattencontrollers auf "SCSI" (LSI SAS) löst das Problem.
Es scheint also mit dem virtuellen NVMe-Controller zusammenzuhängen.

@~thc: Ich steh' grad etwas auf dem Schlauch. (Wie) Kann man bei einer bestehenden VM den Festplattencontroller umstellen? Oder ist das nur durch Neuaufsetzen der VM möglich?

[~thc]

Ich hatte das tatsächlich mit einer VM getestet, die im OOBE-Modus war (nach dem ersten Setup-Neustart) - da geht dann ohnehin alles, da die Hardwareanpassung erst anschließend stattfindet.

Mit einer existierenden VM und fertig installiertem OS ist das etwas umständlicher:

1. Backup
2. VM bearbeiten
3. NVMe-Festplatte löschen (die VMDK wird nicht gelöscht!)
4. Festplatte hinzufügen - SCSI - existierende Festplatte: die "alte" VMDK auswählen

Das OS (ich hatte das mit Win10 x64) läuft jetzt in einen BlueScreen (INACCESSABLE BOOT DEVICE).

Von der Installations-ISO starten (Taste F2 spammen) - Reparaturoptionen - Erweitert - Starthilfe: Diese sagt, es ist nicht möglich, etwas zu reparieren...(!)
Aber es sollte dann funktionieren.

[UpdateFetischist]

SCSI statt NVMe funktioniert! Dieser Workaround löst (für mich) das Problem.

@~thc, @Dayworker: Vielen Dank für eure Hilfe.