[SOLVED] Windows 10 21H2 VMs: Probleme mit März Update KB5011487

[asvetter]

Hallo,
wir haben hier massive Probleme mit Windows 10 21H2 VMs nach dem März Update. Die Maschinen zeigen nach dem Neustart nach der Installation nur den kreisenden Kringel. Weiter starten sie nicht. Wenn man die VMs resettet startet die Automatische Reparatur. Die zeigt auch nur den kreisenden Kringel und endet an einem Blue screen of Death mit dem Stopcode Driver PNP Watchdog. Dann restartet die VM von selbst und es geht von vorn los.

Hat das problem sonst noch jemand?

Wir konnten auf einer VM durch drücken von F8 die Reparatur anwerfen. Dann hat er das März Update rückgängig gemacht und die VM ist normal gestartet. Leider ist es unglaublich schwierig den richtigen Zetpunkt fürs drücken von F8 zu treffen.

Gibt es weitere Lösungsansätze?

Wir haben auch echte Hardware (Fujitsu Esprimo), auf denen das Problem auftaucht, aber nicht auf jeder der baugleichen Kisten.

Ich bin neu hier und weiß nicht, welche weitern Infos gebraucht werden. Werde ich nachliefern.

Gruß, Andreas

 

[Falk R.]

Setz das Update doch erstmal aus, vermutlich ist im April dann ein Fix dafür.

 

[schloegel-edv]

Das Problem tritt immer wieder mal auf. Gibt es dafür eine Lösung?

 

[asvetter]

Wir haben keine Lösung. Hatten das Problem auch im Juni wieder.

 

[itNGO]

PVE-Version? VM-Config? Deutsche Win10-Gäste? Gib doch mal paar Daten....

 

[asvetter]

Den Proxmox macht ein Kollege, deswegen weiss ich jetzt nicht, wann der die letzten Updates gemacht hat. Zustand jetzt:
PVE 7.1-8
In den VMS:
Win 10 21H2 Enterprise deutsch, manche auch Win 10 21H2 Enterprise US-english
Beides betroffen.

Hier die deutsche:
/etc/pve/qemu-server# cat 124.conf
agent: 1
bootdisk: ide0
cores: 4
ide0: lvm-hdd:vm-124-disk-1,size=128G
ide2: local:iso/virtio-win-0.1.208.iso,media=cdrom,size=543390K
machine: pc-q35-5.1
memory: 8192
name: vetter-win10
net0: e1000=26:96:25:F1:2F:8A,bridge=vmbr0
net1: e1000=EA:BD:88:89:EB:C5,bridge=vmbr3,firewall=1
numa: 0
onboot: 1
ostype: win10
scsihw: virtio-scsi-pci
smbios1: uuid=e0b59c1a-8cbb-4763-8e5a-18cf87e4cdb5
sockets: 1


Hier die englische
/etc/pve/qemu-server# cat 100.conf
agent: 1
boot: cdn
bootdisk: scsi0
cores: 2
ide2: none,media=cdrom
memory: 4096
name: tools
net0: virtio=BA:25:E5:BB:22:5D,bridge=vmbr0
numa: 0
onboot: 1
ostype: win10
parent: working
scsi0: lvm-hdd:vm-100-disk-1,size=100G
scsihw: virtio-scsi-pci
smbios1: uuid=341c9044-dca4-4ce9-bfc8-386183006ff2
sockets: 1

[working]
agent: 1
boot: cdn
bootdisk: scsi0
cores: 2
ide2: none,media=cdrom
memory: 4096
name: adadmin-wpyf093
net0: virtio=BA:25:E5:BB:22:5D,bridge=vmbr0
numa: 0
onboot: 1
ostype: win10
scsi0: lvm-hdd:vm-100-disk-1,size=100G
scsihw: virtio-scsi-pci
smbios1: uuid=341c9044-dca4-4ce9-bfc8-386183006ff2
snaptime: 1647624019
sockets: 1

 

[itNGO]

Ich hab grad mal in unserm Patch-Log geschaut.... 05/22 ist was Windows 10/Server 19 etc. angeht ein stabiler Stand.
Das sollte sowohl für Hardware als auch für die VMs helfen... also nur diesen im WSUS freigeben... März war "verhext" und Juni ist es auch wieder.....

Beschwerdebriefe am Besten nach @Redmond schicken.....

 

[asvetter]

Den WSUS habe ich leider nicht unter Kontrolle. Das sind Windowsianer, was soll ich sagen. Auf realer Hardware gab es bei uns im juni auch keine Probleme.

Aber Danke

Ich nehm das WinZeug ja nur gezwungenermaßen, wenn ich die Software nicht in Wine/CrossOver zum laufen kriege.
Und halt zum nachschauen, wie der Menüpunkt heute wieder heißt, wenn ich bei jemand "betreutes klicken" machen muss. Das ändert sich gefühlt auch dauernd.

 

[perry]

Vermutlich auch gerade wieder in dieses Problem gelaufen. Morgens ging nix mehr und ein Blick auf die web console Zeigt folgendes:



Alle beiden Windows VM sind betroffen ... echt nervig! Hoffe Backup einspielen fixt das wieder. Eigentlich dachte ich das ich die Windows Updates ausgeschalten hatte :-(

 

[asvetter]

Hm, meine haben das patchen diesmal überstanden.

 

[perry]

Strange ... hab gerade das Update auf Windows 10 21H2 nochmal manuell getriggert, diesmal lief alles durch und die VM startet ...

 

[perry]

Und täglich grüßt das Murmeltier :-(



Der Fehlercode 0xc000225 bedeutet wohl das Windows das Start-Laufwerk nicht finden kann. Vermutlich wird der entsprechende Treiber beim Update beschädigt oder entfernt. Das ursächliche Update war wohl "2022-10 Kumulatives Update für Windows 10 Version 21H2 für x64-basierte Systeme (KB5018410)".

Hab jetzt folgendes gemacht (vm-1):

1. Backup eingespielt
2. Update Manuell ausgeführt => keine Problem PC startet.
3. VirtIO Treiber auf die aktuelle Version (0.1.221-1) aktualisiert.
4. Netzwerkkonfiguration in der VM ist dadurch verloren gegangen :-( => neu konfiguriert.
5. Neustart, just in case ...

Auf der VM-2 wurde das Update noch nicht automatisch installiert, hab das dann über die Option "Neustarten und Aktualisieren" getriggert. Update ist zwar durchgelaufen, leider hing die VM danach beim booten im "Spinning Circle" fest. Also auch hier:

1. Backup eingespielt
2. Update Manuell ausgeführt => keine Problem PC startet.
3. VirtIO Treiber auf die aktuelle Version (0.1.221-1) aktualisiert.
4. Netzwerkkonfiguration in der VM ist dadurch verloren gegangen :-( => neu konfiguriert.
5. Neustart, just in case ...

Puh hoffentlich hat das VirtIO Treiber Update das Problem jetzt ein für alle mal gefixt.

 

[Palatable2323]

Same problem here today, 5 VMs, Win10 32bit / Win10 64bit / Win11

A quick fix that worked was to STOP + START the VM (not Shutdown, not Reset) during the neverending Winlogo + circle.

That triggered either an auto-rollback of the kb5018410 update (→ succesfull boot), or entered startup/troubleshooting menu - there just choose shutdown ... then the update finished and windows booted up OK.

After that, I upgraded virtio drivers just to be sure.