7
Stabilitätsprobleme bei Windows Server 2019 bis 2025 mit CUs ab etwa 12-24
Moin Zusammen,
heute wurde ich von @Essiess auf den folgenden Artikel ...
https://www.borncity.com/blog/2025/04/02/windows-server-2019-2025-maerz- ...
... vom Günter Born aufmerksam gemacht.
An dieser Stelle möchte ich schon mal sowohl @Essiess für den Tip zu diesem Artikel danken, als auch dem Günter, dass er diesen geschrieben/veröffentlicht hat! 👍👍👍 👏👏👏
Aber, mit ReFS hat das Ganze meiner Ansicht nach nicht wirklich zu tun zumindest nicht ausschliesslich, denn ich beobachte ähnliche Phänomene schon seit Ende des letzten Jahres auch auf den Umgebungen unserer Kunden und diese haben ganz sicher kein ReFS im Einsatz, da alle hardwarebasierte SAN's betreiben. 🙃
Erst gestern war ich den ganzen Tag bei einem Kunden, dessen HV Nodes (WS22) sich seit einigen Wochen aus bisher unerklärlichen Gründen, ständig mit einem Blue-Screen verabschieden, zum Teil mehrfach am Tag und das was ich bisher an diesem System beobachten konnte, deckt sich zu einem grossen Teil auch mit dem, was zum einen Günter in seinem Artikel geschrieben hat, als auch mit den Aussagen in den Kommentaren. Manches ist leider aber auch etwas widersprüchlich.
Und zwar heisst es beim Günter am Anfang des Artikels …
… was sich zunächst danach anhört, dass nur mit CU 25-03 gepatchte Systeme von diesem Problem betroffen sein sollten und auch nur in Verbindung mit ReFS.
Aber, ein Stück weiter unten schreibt der Günter auch das folgende …
… was wiederum darauf hindeutet, dass die Probleme keineswegs erst seit CU 25-03 da sind, sondern eher schon seit mindestens CU24-12. 😔
Bei dem Kunden den ich zuvor angesprochen habe, ist übrigens auf allen seinen produktiven HV-Nodes (WS22) CU25-01 installiert.
Auch das Phänomen mit den 100% CPU Last, konnte ich auf diesem System ebenfalls schon beobachten, aber nicht in Verbindung mit ner iSCSI-Platte, sondern im Zuge mehreren Live-Migration.
Und auch in dem folgenden Kommentar von Blablax …
… sehe ich gewisse Parallelen zu dem was ich selber in letzter Zeit beobachten musste und zwar, dass die Abstürze der HV’s, nicht immer in der Nacht zur Sicherungszeit auftreten.
Ferner sehen die jüngsten beiden Kommentare auch sehr „interessant“ aus …
… 😬😭.
Wie sieht es denn bei euch aus?
Sprich, habt ihr in letzter Zeit auch ähnliche Probleme erleben müssen?
Gruss Alex
heute wurde ich von @Essiess auf den folgenden Artikel ...
https://www.borncity.com/blog/2025/04/02/windows-server-2019-2025-maerz- ...
... vom Günter Born aufmerksam gemacht.
An dieser Stelle möchte ich schon mal sowohl @Essiess für den Tip zu diesem Artikel danken, als auch dem Günter, dass er diesen geschrieben/veröffentlicht hat! 👍👍👍 👏👏👏
Aber, mit ReFS hat das Ganze meiner Ansicht nach nicht wirklich zu tun zumindest nicht ausschliesslich, denn ich beobachte ähnliche Phänomene schon seit Ende des letzten Jahres auch auf den Umgebungen unserer Kunden und diese haben ganz sicher kein ReFS im Einsatz, da alle hardwarebasierte SAN's betreiben. 🙃
Erst gestern war ich den ganzen Tag bei einem Kunden, dessen HV Nodes (WS22) sich seit einigen Wochen aus bisher unerklärlichen Gründen, ständig mit einem Blue-Screen verabschieden, zum Teil mehrfach am Tag und das was ich bisher an diesem System beobachten konnte, deckt sich zu einem grossen Teil auch mit dem, was zum einen Günter in seinem Artikel geschrieben hat, als auch mit den Aussagen in den Kommentaren. Manches ist leider aber auch etwas widersprüchlich.
Und zwar heisst es beim Günter am Anfang des Artikels …
Information für Administratoren von Windows Server 2019, 2022, 23H2 und 2025, die Veeam Backup & Replication verwenden. Deren Veeam Agent for Microsoft Windows macht in Verbindung mit den kumulativen Updates vom März 2025 Probleme. Es kann zu einem Blue Screen of Death (BSOD) mit dem Code 0x00000149 kommen, oder es gibt einen hohen Speicherverbrauch bei ReFS-Datenträgern. Blog-Leser Oliver hat mich per Mail über den Sachverhalt informiert (danke dafür). Veeam hat bereits 2018 einen Support-Beitrag ReFS Known Issues, Considerations, and Limitations zum Thema veröffentlicht, da das Problem nur Datenträger mit ReFS-Dateisystem betrifft.
… was sich zunächst danach anhört, dass nur mit CU 25-03 gepatchte Systeme von diesem Problem betroffen sein sollten und auch nur in Verbindung mit ReFS.
Aber, ein Stück weiter unten schreibt der Günter auch das folgende …
Für Windows Server 2025 gibt es diese Beschreibung von Dezember 2024 im Veeam-Forum. Dort verwendet ein Betroffener eine neue VM-Installation von Windows Server 2025 mit Veeam Backup & Recovery 12.3. Die alte Konfiguration wurde über ein Backup mittels iSCSI und ReFS-Formatierung darauf die neue VM migriert. Der alte Server war Windows Server 2022, wo alles funktionierte.
Nach der Migration gebe es zufällige Abstürze, der Ram-Verbrauch steigt und die CPU ist zu 100% durch den Systemprozess ausgelastet, heißt es. Vom Veeam-Support wurde vorgeschlagen, alle Veeam-Dienste zu stoppen. Das wurde versucht, aber als die iSCSI-Platte wieder angeschlossen wurde, ging die CPU-Last wieder auf 100% hoch.
Als die iSCSI-Backup-Festplatte mit ReFS-Formatierung nicht angeschlossen war und die Veeam-Dienste funktionierten, schien das System stabil zu sein. Im betreffenden Forenthread gibt es mehrere andere Nutzer, die dieses Verhalten bestätigen.
Nach der Migration gebe es zufällige Abstürze, der Ram-Verbrauch steigt und die CPU ist zu 100% durch den Systemprozess ausgelastet, heißt es. Vom Veeam-Support wurde vorgeschlagen, alle Veeam-Dienste zu stoppen. Das wurde versucht, aber als die iSCSI-Platte wieder angeschlossen wurde, ging die CPU-Last wieder auf 100% hoch.
Als die iSCSI-Backup-Festplatte mit ReFS-Formatierung nicht angeschlossen war und die Veeam-Dienste funktionierten, schien das System stabil zu sein. Im betreffenden Forenthread gibt es mehrere andere Nutzer, die dieses Verhalten bestätigen.
… was wiederum darauf hindeutet, dass die Probleme keineswegs erst seit CU 25-03 da sind, sondern eher schon seit mindestens CU24-12. 😔
Bei dem Kunden den ich zuvor angesprochen habe, ist übrigens auf allen seinen produktiven HV-Nodes (WS22) CU25-01 installiert.
Auch das Phänomen mit den 100% CPU Last, konnte ich auf diesem System ebenfalls schon beobachten, aber nicht in Verbindung mit ner iSCSI-Platte, sondern im Zuge mehreren Live-Migration.
Und auch in dem folgenden Kommentar von Blablax …
Kann ich bestätigen. Maschinen stürzen einfach alle paar Tage ab und werfen einen BSOD. Hatten erst in einer anderen Richtung gesucht. Auf Veeam wäre ich nicht gleich gestoßen, da der BSOD nicht immer in der Nacht zur Sicherungszeit aufgetreten ist.
… sehe ich gewisse Parallelen zu dem was ich selber in letzter Zeit beobachten musste und zwar, dass die Abstürze der HV’s, nicht immer in der Nacht zur Sicherungszeit auftreten.
Ferner sehen die jüngsten beiden Kommentare auch sehr „interessant“ aus …
… 😬😭.
Wie sieht es denn bei euch aus?
Sprich, habt ihr in letzter Zeit auch ähnliche Probleme erleben müssen?
Gruss Alex
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672317
Url: https://administrator.de/forum/stabilitaetsprobleme-bei-windows-server-2019-bis-2025-mit-cus-ab-etwa-12-24-672317.html
Ausgedruckt am: 06.04.2025 um 09:04 Uhr
7 Kommentare
Neuester Kommentar
Moin,
Ich bin gerade hin und her gerissenen, ob ich unseren VEEAM-Server mal noch aktualisiere oder erst einmal noch nicht.
Da er keine Verbindung ins WAN/ LAN hat (außer zum Sichern), kann ich damit noch ein paar Tage leben.
Allerdings haben wir das VEEAM BackupRepository an ein FC-SAN angebunden. Die gemappte LUN (60TB) haben wir dann mit ReFS formatiert.
Ich bin gerade hin und her gerissenen, ob ich unseren VEEAM-Server mal noch aktualisiere oder erst einmal noch nicht.
Da er keine Verbindung ins WAN/ LAN hat (außer zum Sichern), kann ich damit noch ein paar Tage leben.
Allerdings haben wir das VEEAM BackupRepository an ein FC-SAN angebunden. Die gemappte LUN (60TB) haben wir dann mit ReFS formatiert.
Moin @em-pie,
momentan sieht es für mich eher danach aus, als ob Veeam das Problem eher nur massiv antriggert aber nicht wirklich der Grund für den Absturz ist, da diese wie schon geschrieben, auch ausserhalb der Sicherungszeiten vorkommen. 😔
Mein bauchgefühl sagt mir momentan, dass man eher die von MS aussetzen sollte.
Wir haben vor Jahren mal eine ~250 TB Backup-LUN mit ReFS bei einem Kunden in betrieb genommen, weil auch schon damals Veeam selbst dafür ReFS empfohlen hat.
Nadem diese LUN dann zwei Mal innerhalb eines Jahres "abgeraucht" ist, haben wir diese mit NTFS neu formatiert und hatten danach bei diesem Kunden nie wieder ähnliche Probleme.
Gruss Alex
P.S. Heute nacht ist bei dem im Hauptpost angesprochenem Kunden, schon wieder ein HV weggeflogen. 😭
Ich bin gerade hin und her gerissenen, ob ich unseren VEEAM-Server mal noch aktualisiere oder erst einmal noch nicht.
momentan sieht es für mich eher danach aus, als ob Veeam das Problem eher nur massiv antriggert aber nicht wirklich der Grund für den Absturz ist, da diese wie schon geschrieben, auch ausserhalb der Sicherungszeiten vorkommen. 😔
Mein bauchgefühl sagt mir momentan, dass man eher die von MS aussetzen sollte.
Allerdings haben wir das VEEAM BackupRepository an ein FC-SAN angebunden. Die gemappte LUN (60TB) haben wir dann mit ReFS formatiert.
Wir haben vor Jahren mal eine ~250 TB Backup-LUN mit ReFS bei einem Kunden in betrieb genommen, weil auch schon damals Veeam selbst dafür ReFS empfohlen hat.
Nadem diese LUN dann zwei Mal innerhalb eines Jahres "abgeraucht" ist, haben wir diese mit NTFS neu formatiert und hatten danach bei diesem Kunden nie wieder ähnliche Probleme.
Gruss Alex
P.S. Heute nacht ist bei dem im Hauptpost angesprochenem Kunden, schon wieder ein HV weggeflogen. 😭
Moin Zusammen,
heute Nacht ist bei dem entsprechenden Kunden schon wieder ein HV-Node abgeraucht ...
... und zwar ohne, dass zuvor auch nur eine einzige Fehlermeldung ins System-Ereignislog geschrieben wurde. 😔😭
Gruss Alex
heute Nacht ist bei dem entsprechenden Kunden schon wieder ein HV-Node abgeraucht ...
... und zwar ohne, dass zuvor auch nur eine einzige Fehlermeldung ins System-Ereignislog geschrieben wurde. 😔😭
Gruss Alex
Moin Zusammen,
es sind zwar vor dem Absturz keine Fehlermeldungen im System-Ereignislog zu sehen gewesen, nach dem Reebot tauchen jedoch schon ein paar interessante auf und zwar die folgenden.
😬 ... mal schauen was im MEMORY.DMP steht.
Gruss Alex
P.S. Der MEMORY.DMP hat 50 GB. 😭
es sind zwar vor dem Absturz keine Fehlermeldungen im System-Ereignislog zu sehen gewesen, nach dem Reebot tauchen jedoch schon ein paar interessante auf und zwar die folgenden.
Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x000000d1 (0x0000000000004478, 0x0000000000000002, 0x0000000000000000, 0xfffff8027a12f872). Ein volles Abbild wurde gespeichert in: C:\Windows\MEMORY.DMP. Berichts-ID: a70134ac-2543-4ac8-9e94-e45fc4ffc6f9.
😬 ... mal schauen was im MEMORY.DMP steht.
Gruss Alex
P.S. Der MEMORY.DMP hat 50 GB. 😭
Moin Zusammen,
interessanterweise gibt es zu dem oberen Fehler, den folgenden ...
https://learn.microsoft.com/de-de/troubleshoot/windows-server/performanc ...
... relativ neuen Artikel von MS selbst, in dem jedoch über Probleme bei 2012R2 Systemen berichtet wird, der jedoch seit 10 October 2023 EoS ist.
Was die folgende Aussage de MS Artikels ...
... ja dann wiederum absolut absurd macht. 😔
Sprich, entweder hat sich MS im Artikel bei der Eingrenzung auf nur 2012R2 etwas vertan oder ... sie haben in den aktuellen CU's eventuell den fehlehrhaften Code aus dem 2012R2 wiederverwendet. 🙃
Gruss Alex
Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x000000d1 (0x0000000000004478, 0x0000000000000002, 0x0000000000000000, 0xfffff8027a12f872). Ein volles Abbild wurde gespeichert in: C:\Windows\MEMORY.DMP. Berichts-ID: a70134ac-2543-4ac8-9e94-e45fc4ffc6f9.
interessanterweise gibt es zu dem oberen Fehler, den folgenden ...
https://learn.microsoft.com/de-de/troubleshoot/windows-server/performanc ...
... relativ neuen Artikel von MS selbst, in dem jedoch über Probleme bei 2012R2 Systemen berichtet wird, der jedoch seit 10 October 2023 EoS ist.
Was die folgende Aussage de MS Artikels ...
... ja dann wiederum absolut absurd macht. 😔
Sprich, entweder hat sich MS im Artikel bei der Eingrenzung auf nur 2012R2 etwas vertan oder ... sie haben in den aktuellen CU's eventuell den fehlehrhaften Code aus dem 2012R2 wiederverwendet. 🙃
Gruss Alex
Sprich, entweder hat sich MS im Artikel bei der Eingrenzung auf nur 2012R2 etwas vertan oder ... sie haben in den aktuellen CU's eventuell den fehlehrhaften Code aus dem 2012R2 wiederverwendet. 🙃
Moin Alex,
würde mich nicht wundern.
Viele Grüße
Andreas
Hallo zusammen,
habe hier zwar nicht die größte Umgebung, aber die 3 Hyper-V Hosts @2022 und die VMs mit 2016 (einer noch) bis 2022 zeigen auch im Zusammenhang mit Veeam BaR keine Instabilitäten.
Ich habe zwar die Ereignisprotokolle nicht explizit im Blick, aber Neustarts würden in der Hyper-V Verwaltung bei der Laufzeit auffallen.
Dienstag ist aber ja diesen Monat schon wieder Patchday.
Grüße
ToWa
habe hier zwar nicht die größte Umgebung, aber die 3 Hyper-V Hosts @2022 und die VMs mit 2016 (einer noch) bis 2022 zeigen auch im Zusammenhang mit Veeam BaR keine Instabilitäten.
Ich habe zwar die Ereignisprotokolle nicht explizit im Blick, aber Neustarts würden in der Hyper-V Verwaltung bei der Laufzeit auffallen.
Dienstag ist aber ja diesen Monat schon wieder Patchday.
Grüße
ToWa
