[English]Ich ziehe mal einen Sachverhalt separat in einen Beitrag, der mir seit dem Juni 2025-Patchday berichtet wird. Nutzer der Virtualisierungsplattform Proxmox sowie unter KVM/QEMU bekommen bei virtualisierten Windows-VMs BlueScreens, sobald sie die Updates von Juni 2025 installieren. Es betrifft betrifft (Proxmox) Hosts mit AMD-CPUs (Ryzen & Epyc). Der Fehler ist bekannt und es gibt auch einen Workaround.
Anzeige
Windows Juni 2025-Updates
Zum 10. Juni 2025 hat Microsoft zahlreiche Sicherheitsupdates für die noch unterstützten Windows-Versionen veröffentlicht. Diese hatte ich für Windows Clients im Blog-Beitrag Patchday: Windows 10/11 Updates (10. Juni 2025) aufgeführt. Für Windows 11 24H2 gab es dann noch das Out-of-Band-Update, welches im Beitrag Windows 11 24H2: Out-of-Band-Update KB5063060 erwähnt wurde. Die Updates für die Server sind im Beitrag Patchday: Windows Server-Updates (10. Juni 2025) beschrieben. Alle Sicherheitsupdate schließen gravierende Schwachstellen, die ich im Beitrag Microsoft Security Update Summary (10. Juni 2025) sowie in weiteren, am Artikelende verlinkten Beiträgen behandelt habe.
Lesermeldung zum Proxmox BSOD-Problem
Christof P. hatte mich bereits zum 12. Juni 2025 per E-Mail kontaktiert, weil er in ein Problem gelaufen ist und nicht alleine betroffen scheint. Er schrieb mir seinerzeit, dass die neuesten Updates für Windows 11 und Server 2025 in virtuellen Maschinen (VMs) massive Probleme bereiten, wenn diese unter Proxmox laufen.
Nach der Update-Installation und dem Reboot schmieren die VMs mit einem BlueScreen (BSOD) "Unsupported Processor" ab. Dies betrifft Proxmox-Hosts mit AMD-CPUs (Ryzen & Epyc). Der Leser konnte das Problem selbst auf einigen von ihm betreuten Kundensystemen nachvollziehen.
Es hilft dann nur die Umstellung der virtuellen CPU auf ein generisches Modell (beispielsweise "x86-64-ve") oder eine emulierte Epyc-CPU. Dies betrifft unter Windows 11 "nur" die neuesten Versionen, also 24H2. 23H2 oder IoT LTSC Versionen sind hiervon nicht betroffen.
Leserdiskussion im Blog
Im Blog hatte sich Leser Meth0d bereits zum 11. Juni 2025 mit diesem Kommentar gemeldet und schrieb, dass er nach den Updates einen BSOD mit der Meldung UNSUPPORTED PRCOCESSOR in seiner Test VM bekomme, die unter Proxmox auf einem Host mit einer EPYC 9374F CPU läuft.
Anzeige
Bolko hat sich in diesem Kommentar dann gemeldet und, unter Verweis auf diverse Fundstellen, geliefert. Auf reddit.com gibt es den Sammel-Thread Cumulative Updates: June 10th 2025, in dem es um die Juni 2025-Updates geht. Dort gibt es diese Diskussion, dass Windows-Maschinen mit AMD-Prozessoren die Updates nicht bekommen.
Bolko fragt, welche Funktion denn ein AMD Ryzen nicht können soll, so dass Microsoft da extra eine Abfrage in die Windows-Update-Verteilung einbaut? Er schreibt, dass dies sogar für AMD Ryzen 5000 Threadripper gelte. Er merkt an, dass es in den nächsten Tagen weitere Updates geben soll, um das AMD-Problem zu adressieren.
Bei heise gibt es den Foren-Thread KVM/QEMU Ryzen den kb5060842,KB5058499 nicht installieren!, der sich auf KVM/Qemu bezieht und das gleiche Problem betrifft (danke an Bolko für den Link).
Proxmox-Forum: Diskussion und Workaround
Blog-Leser Christof hatte mir in seiner E-Mail einen Link auf den Thread AMD : BSOD unsupported processor since Windows build 26100.4202+ ( update kb5060842 + its preview kb5058499 ) im Proxmox-Forum geliefert. Dort wird der BSOD unter Windows 11 diskutiert.
Der Workaround, so schrieb mir Christof, und das wird auch andernorts bestätigt, besteht in der Umstellung der virtuellen CPU auf ein generisches Modell (bspw. "x86-64-ve") oder eine emulierte Epyc CPU. Dies betrifft unter Windows 11 "nur" die neuesten Versionen, also 24H2. Windows 11 23H2 oder IoT LTSC Versionen sind laut Christof hiervon nicht betroffen.
Erfahrung eines Lesers
Ergänzung: Im Nachgang zu diesem Artikel hat sich ein ungenannt bleiben wollender Blog-Leser gemeldet und folgende Erkenntnisse mitgeteilt. Beim Hoster Hetzner gibt es bei den (nicht offiziell Windows-unterstützenden) Cloud-Servern mit AMD-CPU die selben Probleme unter Windows Server 2025. Das Gleiche gilt beim Hoster Netcup, wobei Netcup laut Leser hier bereits nachgesteuert habe. Der Hoster Hetzner "ziert sich bislang hingegen ein wenig und redet sich mit der nicht offiziellen Unterstützung heraus", schrieb der Leser.
Ähnliche Artikel:
Microsoft Security Update Summary (10. Juni 2025)
Patchday: Windows 10/11 Updates (10. Juni 2025)
Patchday: Windows Server-Updates (10. Juni 2025)
Patchday: Microsoft Office Updates (10. Juni 2025)
Windows 11 24H2: Out-of-Band-Update KB5063060
Windows 10/11: Preview Updates 27. /28. Mai 2025
Windows 10: Juni 2025-Update KB5060533 verursacht Surface Hub v1-Bootfehler
Vorsicht: Windows Juni 2025-Updates bricken Fujitsu-Rechner
Juni 2025-Patchday soll Schwachstelle CVE-2025-33073 in Windows schließen
Windows Netzwerkschwachstelle CVE-2025-33073 (Reflective Kerberos Relay Attack)
Anzeige
Unabhängig von der Frage was Microsoft da wieder treibt, wäre die Frage warum sich hier KVM-Systeme von echten System mit Ryzen CPU unterscheiden. Hier scheint das Problem ja nicht aufzutreten.
Einerseits die Software zur Virtualisierung selbst. Anderseits die speziellen Hardwarefunktionen des Rechners zur Virtualisierung.
Die emulierten CPUs (AMD, Intel) entsprechen vom Funktionsumfang nicht der im Gerät verbauten CPU. Da "fehlen" dann ganz einfach die Funktionen (und evtl. auch Microcodes). Der Typ "HOST" reicht 1:1 durch. Oftmals wird der Typ HOST empfohlen, weil du dann auch die maximale Performance hast. Einige Funktionen und Features lassen sich nur mit CPU HOST nutzen.
Dazu kommen dann aber auch noch die Treiberversion für die Virtio Plattform und auch hier gibt es teilweise Probleme mit den neueren Windows Servern und den neusten Treibern.
Das Proxmox Forum hat hier einige Threads und "Glaubensrichtungen"
Hier mal eine Aufschlüsselung der Qemu CPUs
https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html
Proxmox ist derzeit einzige vernünftig und sinnvolle Option für private Cloud. Meine Meinung.
HOST als CPU Type ist nicht zu empfehlen, wenn man live Migration nutzen möchte.
eine VM weiß, dass sie virtuell läuft. Prozesse können dies als Feature abfragen. Außerdem werden Prozessoren schon immer an Flags entsprechend identifiziert.
Wen ich so was lese muss ich unweigerlich wieder zurück in die späten 80er, frühen 90er denken, wie MS mit DR-DOS umgegangen ist, BSOD in Win3 nur nach einer Abfrage ob DR-DOS verwendet wird.
Kam alles erst 10 Jahre später raus im Anti-Trust Verfahren gegen Microsoft.
Warum kauft und nutzt Ihr deren Scheiß eigentlich noch?
Weil man darauf angewiesen ist. Es gibt nun mal manche Fachsoftware nicht für Linux oder andere Betriebssysteme. Das kann man ganz ganz doof finden, ändert aber an der Tatsache heute auch nichts. Das ist etwas was am besten auf EU Ebene geregelt werden müsste. Angefangen damit, dass man standardmäßig auf freie Office Formate setzt, anschließend kann man fordern, dass neue Software für Behörden plattformunabhängig funktionieren muss und irgendwann wenn das durch ist, kann man mal sagen, dass Bestandssoftware bis X umgestellt sein muss.
wovon träumen Sie nachts? Ende von 10 wird ab Oktober dann wieder containerweise Schrott erstellen, alleine schon wegen TPM 2.
#endOf10
Sogenannte "Fachsoftware", die nur unter System XYZ zu betreiben ist, wird virtualisiert. Wenn jedoch diese sogenannte "Fachsoftware" Probleme mit standardisierten Virtualisierungen hat, wessen Problem ist das nochmal?
Ja, und auf welchem BS läuft die dann in der virtuellen Welt? Wieviele VMs braucht man da? Wieviel kosten die BS-Lizenzen? Wieviel mehr Wartungsaufwand bedeutet das, wenn man neben den virtuellen Windows-BS mit der Fachananwendung auch noch physische Linux Systeme supporten muss? Was ist, wenn die Benutzer 99% ihrer Zeit in der VM verbringen, wollen die das dann vielleicht doch lieber wieder lokal haben?
Das Problem war vor dem Update schon spürbar, sobald ein Server 2025 in einer Domain hing war die Performance nur noch ca. 1/5.
Wenn man den "Workaround" von hier angewendete war die Performance wieder voll da.
Soweit man die Microsoft Ticketantwort für voll nehmen kann soll es wohl an einem Problem bzgl. Hardware-Root-of-Trust im zusammenhang mit KVM (Nicht nur Proxmox) liegen.
emuliert oder nativ? Zertifikatsproblem?
Trifft das Problem eigentlich nur Proxmox-(KVM/Qemu)-User oder haben VMware-User das gleiche Problem?
Bei VMWare gibt es diesbezüglich keinerlei Probleme. Das Thema hängt am AMD-Prozessor und nicht wirklich an KVM. Bei Intel-CPUs soll das angeblich nicht vorkommen. So habe ich es zumindest in anderen Berichten gelesen.
genau deshalb gibt es Virtualisierung, was nicht funktioniert wird emuliert.
Also ich hab grad nen per Proxmox virtualisierten Windows Server 2025 (cpu-type=host) auf die Build-Version 26100.4349 aktualisiert und keinen BSOD bekommen. CPU ist ein AMD Epyc 8124P – AMD 16 Core Zen4c Siena Plattform. Die CPU scheint dann wohl nicht betroffen zu sein?
Nein, es betrifft nicht alle Serien von Zen CPUs.
Interessant, haben hier 9554, 9334 und sogar 9174F die betroffen waren.
Aktuell scheint es eh eine Menge Probleme mit KVM und AMD CPUs zu geben.WINEP-61407 Central Endpoint/Server – Windows https://docs.sophos.com/support/kil/index.html.
USB 3.0 HDD an Lenovo Ryzen Notebook angestöpselt: BSOD und das nachvollziehbar.
Sowas braucht kein Mensch, seitdem keine Systeme mehr mit AMD CPU verkauft und ruhig geschlafen.
Neu sind die Probleme nicht:
"KVM advertises ARCH_CAPABILITIES regardless of hardware support
Solution Verified – Updated June 14 2024 at 1:35 AM
The CPUID flag ARCH_CAPABILITIES is unconditionally exposed to host userspace for all x86 hosts, i.e. KVM advertises ARCH_CAPABILITIES regardless of hardware support under the pretense that KVM fully emulates MSR_IA32_ARCH_CAPABILITIES. Unfortunately, only VMX hosts handle accesses to MSR_IA32_ARCH_CAPABILITIES (despite KVM_GET_MSRS also reporting MSR_IA32_ARCH_CAPABILITIES for all hosts).
This can result in guests not booting due to kernel panics.
https://access.redhat.com/solutions/5056751
Hallo zusammen,
ich habe dasselbe Problem mit einer EPYC-CPU auf einem Server bei Hetzner.
Das Problem besteht weiterhin – derzeit habe ich die Updates deaktiviert, was natürlich keine gute Lösung ist.
Die Antwort von Hetzner:
Nach aktuellem Stand wird das Problem durch das Update selbst verursacht und betrifft virtuelle Maschinen.
Bitte beachten Sie, dass Windows Server 2025 kein offiziell unterstütztes Betriebssystem auf unserer Cloud-Console ist. Entsprechend können wir bei Problemen durch Updates oder Kompatibilitätsänderungen seitens Microsoft leider keinen Support anbieten.
Wir beobachten die Situation und werden, falls es künftig Optionen zur Abhilfe auf unserer Seite geben sollte, diese prüfen.
Wir empfehlen die betroffenen Maschinen mithilfe von Snapshots oder Backups wiederherzustellen und sich direkt an Microsoft zu wenden.
Hast du bei Hetzner nicht (teilweise) die Möglichkeit auf den VM-Host direkt zuzugreifen bzw. auf bestimmte Funktionen? Dann könntest du ggf. die CPU-Kompatibilitätseinstellung ändern.
Die Antwort von Hetzner:
Nach aktuellem Stand liegt die Ursache für das beobachtete Verhalten beim Update selbst bzw. bei Microsoft und nicht in unserer Infrastruktur. Aus diesem Grund bitten wir um Verständnis, dass wir in diesem Fall leider keine weiteren Maßnahmen oder Einzeländerungen anbieten.
Der Anbieter Shadow Cloud Gaming PC hat das selbe Problem, der Link führt zu der Status Seite: [Global] – 20/06/2025 – Incident – BSOD when upgrading to Windows 11