25
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: 26.04.2025 um 20:04 Uhr
25 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
Moin @dertowa,
wir kommen dem Problem glaube ich so langsam auf die Schliche.
Und zwar haben wir bisher herausgefunden, dass warum auch immer, seit einigen Wochen die NIC’s (Intel X710) der entsprechenden Hyper-V Nodes, sporadisch für mehrere Sekunden offline gehen. 😬
Auf dem Core-Switch (ARUBA 5412R ZL2) an dem diese dranhängen, sieht man trotz aktiviertem Fault-Finder, jedoch nicht wirklich einen Fehler, sondern nur eine Meldung, dass der entsprechende Port offline und kurz danach wieder online gegangen ist. 😭
Bei dem entsprechenden Kunden war zudem SR-IOV auf vielen vNIC’s aktiviert und eine SR-IOV enabled vNIC reagiert auf einen plötzlichen Linkverlust zudem ganz anders wie eine nicht Hardwarebeschleunigte vNIC. Was wahrscheinlich die überproportional häufigen Abstürze erklären würde.
Nun gilt es genau herauszufinden, warum die X710 Port immer wieder offline gehen.
Aber, das Einzige was an dem System grossartig verändert wurde bevor die Probleme begannen, war die Installation von CU25-01. 😔
Ich bin mir nicht ganz sicher, ob mich diesbezüglich nun freuen oder lieber weinen sollte. 🙃
Gruss Alex
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.
Ich habe zwar die Ereignisprotokolle nicht explizit im Blick, aber Neustarts würden in der Hyper-V Verwaltung bei der Laufzeit auffallen.
wir kommen dem Problem glaube ich so langsam auf die Schliche.
Und zwar haben wir bisher herausgefunden, dass warum auch immer, seit einigen Wochen die NIC’s (Intel X710) der entsprechenden Hyper-V Nodes, sporadisch für mehrere Sekunden offline gehen. 😬
Auf dem Core-Switch (ARUBA 5412R ZL2) an dem diese dranhängen, sieht man trotz aktiviertem Fault-Finder, jedoch nicht wirklich einen Fehler, sondern nur eine Meldung, dass der entsprechende Port offline und kurz danach wieder online gegangen ist. 😭
Bei dem entsprechenden Kunden war zudem SR-IOV auf vielen vNIC’s aktiviert und eine SR-IOV enabled vNIC reagiert auf einen plötzlichen Linkverlust zudem ganz anders wie eine nicht Hardwarebeschleunigte vNIC. Was wahrscheinlich die überproportional häufigen Abstürze erklären würde.
Nun gilt es genau herauszufinden, warum die X710 Port immer wieder offline gehen.
Aber, das Einzige was an dem System grossartig verändert wurde bevor die Probleme begannen, war die Installation von CU25-01. 😔
Dienstag ist aber ja diesen Monat schon wieder Patchday.
Ich bin mir nicht ganz sicher, ob mich diesbezüglich nun freuen oder lieber weinen sollte. 🙃
Gruss Alex
Zitat von @MysticFoxDE:
Ich bin mir nicht ganz sicher, ob mich diesbezüglich nun freuen oder lieber weinen sollte. 🙃
Gruss Alex
Ich bin mir nicht ganz sicher, ob mich diesbezüglich nun freuen oder lieber weinen sollte. 🙃
Gruss Alex
Hey,
probiere es doch aus, steht ja nun zur Verfügung.
Wobei nach der letzten Schilderung klingt das schon eher speziell, da muss man Microsoft wohl eher mit der Nase in den Haufen schieben, damit die das riechen.
...ggf. können die aber auch nix dazu?
Die Treiber der Netzwerkkarten hast du im Blick, Intel hat am 27.02.25 die Version 30.0.1 rausgehauen.
Grüße
ToWa
Moin @dertowa,
nicht vor Sammstag und danach ist wahrscheinlich mein ganzes WE wieder am A.... . 😔
Doch doch, die können sehr wohl was dafür und zwar so wie es aussieht als Hauptverantwortliche! 😡
Jup, die habe ich im Blick und genau die, sowie auch die passende NVE/Firmware für die NIC's und auch das neuste BIOS für die Server, wurde bereits letzte Woche auf den entsprechenden Systemen eingespielt, wudurch sich die Lage gefühlt sogar etwas verschlechtert hat. 😭
Aber alles der reihe nach.
Ich habe gestern auf einem anderen System nachgeschaut, welches sogar auf CU25-03 gepatcht ist und auch welchem ebenfalls schon die neusten Intel Treiber+NVM's installiert sind und habe bei diesem im Ereignislog das folgende zu sehen bekommen.
Sprich, auch bei diesem Kunden verlieren die NIC's sporadisch die Verbindung. 😭
Aber, dieser Kunde hat bisher keinen Absturz gemeldet, sehr wohl aber andere Probleme, die ich durch die nun gefundene Port-Trennung, nun auch besser zuordnen kann.
Dieser Kunde kat trotzt der Portausfälle bisher jedoch noch keinen Komplettausfall/Reboot eines Hosts gemeldet, was jedoch wahrscheinlich damit zu tun hat, dass bei diesem bewusst kein SR-IOV (weil nur 1G geswitcht) verwendet wurde.
Und auch bei diesem Kunden, sind die Probleme erst dann aufgetaucht, nachdem das System jüngst auf CU25-03 gepatcht wurde. 😔
Dann habe ich mir als nächstes ein System (Ebenfalls HV22) angesehen, was definitiv schon länger nicht mehr gepatcht wurde und siehe da ...
... auf diesem sind überhaupt keine vergleichbaren Fehler zu sehen ...
und das bei einer Uptime von über einem Jahr!
Sprich, damit ist nun wohl eindeutig bewiesen wer das Problem verursacht hat, sprich Microsoft mit ihren CU's.
Und das erklärt auch die Bluescreens bei den anderen in Verbindung mit Veeam, denn vor allem Veeam kann es überhaupt nicht leider, wenn während einer Sicherung auf einmal die NIC's wegfallen, über die die Backupdaten transferiert werden.
So, wie kommen wir aus dieser Sch..sse nun wieder raus?
Gruss Alex
probiere es doch aus, steht ja nun zur Verfügung.
nicht vor Sammstag und danach ist wahrscheinlich mein ganzes WE wieder am A.... . 😔
Wobei nach der letzten Schilderung klingt das schon eher speziell, da muss man Microsoft wohl eher mit der Nase in den Haufen schieben, damit die das riechen.
...ggf. können die aber auch nix dazu?
...ggf. können die aber auch nix dazu?
Doch doch, die können sehr wohl was dafür und zwar so wie es aussieht als Hauptverantwortliche! 😡
Die Treiber der Netzwerkkarten hast du im Blick, Intel hat am 27.02.25 die Version 30.0.1 rausgehauen.
Jup, die habe ich im Blick und genau die, sowie auch die passende NVE/Firmware für die NIC's und auch das neuste BIOS für die Server, wurde bereits letzte Woche auf den entsprechenden Systemen eingespielt, wudurch sich die Lage gefühlt sogar etwas verschlechtert hat. 😭
Aber alles der reihe nach.
Ich habe gestern auf einem anderen System nachgeschaut, welches sogar auf CU25-03 gepatcht ist und auch welchem ebenfalls schon die neusten Intel Treiber+NVM's installiert sind und habe bei diesem im Ereignislog das folgende zu sehen bekommen.
Sprich, auch bei diesem Kunden verlieren die NIC's sporadisch die Verbindung. 😭
Aber, dieser Kunde hat bisher keinen Absturz gemeldet, sehr wohl aber andere Probleme, die ich durch die nun gefundene Port-Trennung, nun auch besser zuordnen kann.
Dieser Kunde kat trotzt der Portausfälle bisher jedoch noch keinen Komplettausfall/Reboot eines Hosts gemeldet, was jedoch wahrscheinlich damit zu tun hat, dass bei diesem bewusst kein SR-IOV (weil nur 1G geswitcht) verwendet wurde.
Und auch bei diesem Kunden, sind die Probleme erst dann aufgetaucht, nachdem das System jüngst auf CU25-03 gepatcht wurde. 😔
Dann habe ich mir als nächstes ein System (Ebenfalls HV22) angesehen, was definitiv schon länger nicht mehr gepatcht wurde und siehe da ...
... auf diesem sind überhaupt keine vergleichbaren Fehler zu sehen ...
und das bei einer Uptime von über einem Jahr!
Sprich, damit ist nun wohl eindeutig bewiesen wer das Problem verursacht hat, sprich Microsoft mit ihren CU's.
Und das erklärt auch die Bluescreens bei den anderen in Verbindung mit Veeam, denn vor allem Veeam kann es überhaupt nicht leider, wenn während einer Sicherung auf einmal die NIC's wegfallen, über die die Backupdaten transferiert werden.
So, wie kommen wir aus dieser Sch..sse nun wieder raus?
Gruss Alex
Moin Zusammen,
an alle die insbesondere Hyper-V 2022 mit CU >= 24-12 betreiben.
Könnt ihr bitte in der Ereignisanzeige (System Log) euerer HV's mal nachschauen, ob dort ebenfalls ähnliche Meldungen mit der ID 27 zu sehen sind, danke.
Gruss Alex
an alle die insbesondere Hyper-V 2022 mit CU >= 24-12 betreiben.
Könnt ihr bitte in der Ereignisanzeige (System Log) euerer HV's mal nachschauen, ob dort ebenfalls ähnliche Meldungen mit der ID 27 zu sehen sind, danke.
Gruss Alex
Hallo Fox,
aber gern doch...
HyperV01 (Server 2022 Datacenter 03-25)
HyperV02 (Server 2022 Datacenter 03-25)
HyperVM (Server 2022 Standard 03-25)
Keine "akuten" Events, lustigerweise aber wenn dann immer nur Intel NICs, die für den produktiven Betrieb genutzten Broadcom 10Gs gibt es nicht in der Liste.
An Intels werden genutzt:
Grüße
ToWa
aber gern doch...
HyperV01 (Server 2022 Datacenter 03-25)
HyperV02 (Server 2022 Datacenter 03-25)
HyperVM (Server 2022 Standard 03-25)
Keine "akuten" Events, lustigerweise aber wenn dann immer nur Intel NICs, die für den produktiven Betrieb genutzten Broadcom 10Gs gibt es nicht in der Liste.
An Intels werden genutzt:
- i350-T4 (HyperV01 & 02)
- i210-T1 (HyperVM)
- PRO/1000PT (HyperVM)
Grüße
ToWa
1
Moin Zusammen,
auch bei einem weiteren Kunden, dessen HV's auch auf WS22 aber mit CU24-05 laufen ...
... gibt es im Ereignislog keine Meldungen mit ID 27.
Die Hardware dieses Kunden, ist übrigens zu den beiden davor fast identisch.
Sprich, CU24-05 und die folgenden Intel NIC Treiber und entsprechende NVE's ...
... sind auch safe. 🙃
Gruss Alex
auch bei einem weiteren Kunden, dessen HV's auch auf WS22 aber mit CU24-05 laufen ...
... gibt es im Ereignislog keine Meldungen mit ID 27.
Die Hardware dieses Kunden, ist übrigens zu den beiden davor fast identisch.
Sprich, CU24-05 und die folgenden Intel NIC Treiber und entsprechende NVE's ...
... sind auch safe. 🙃
Gruss Alex
Hallo noch mal,
da ich in meiner Workstation (Windows 11 Pro 24H2) Intel NICs habe...
Dort tauchen auf:
Grüße
ToWa
da ich in meiner Workstation (Windows 11 Pro 24H2) Intel NICs habe...
Dort tauchen auf:
- Intel(R) Ethernet Converged Network Adap... [5,0,1]
- Intel X550-T2
Grüße
ToWa
1
Moin @dertowa,
danke für die flinke Rückmeldung! 👍
🤔 ... auch interessant, sprich, so wie es aussieht, betrifft das Problem bisher wohl nur Intel NIC's. 😬
Bei den Systemen unserer Kunden sind überwiegend Intel X7xx oder I350 verbaut.
Gruss Alex
aber gern doch...
danke für die flinke Rückmeldung! 👍
Keine "akuten" Events, lustigerweise aber wenn dann immer nur Intel NICs, die für den produktiven Betrieb genutzten Broadcom 10Gs gibt es nicht in der Liste.
🤔 ... auch interessant, sprich, so wie es aussieht, betrifft das Problem bisher wohl nur Intel NIC's. 😬
An Intels werden genutzt:
- i350-T4 (HyperV01 & 02)
- i210-T1 (HyperVM)
- PRO/1000PT (HyperVM)
Bei den Systemen unserer Kunden sind überwiegend Intel X7xx oder I350 verbaut.
Gruss Alex
Moin @dertowa,
👍👍👍 👏👏👏 das ist ein sehr interessanter Hinweis!
Sprich, somit sind von dem Problem nicht nur die Server betroffen, sondern auch die Clients, die W11 haben wiederum aber auch den gleichen Kernel wie die Server verbaut. 🙃
Ich habe soeben auf der Workstation meines Kollegen nachgesehen, welche mit W11 24H2 Enterprise und CU25-03 läuft und bei dieser sind ebenfalls die Fehler mit ID 27 zu sehen.
Und jetzt kommt was total wirres, denn die Meldungen betreffen nicht nur die NIC, sprich, die I219-V die auch wirklich online ist, sondern auch die beiden Ports der in dieser Workstation verbauten X540 ...
... die jedoch keinen Uplink haben und somit auch nicht wirklich die Netzwerkverbindung verlieren können.
Ja, ich weiss ... 😖😵💫🙊🙈
Ohh, es wird noch gruseliger, schau mal was auf dieser Workstation für Treiber installiert sind ...
... und das obwohl ...
... 🤮🤮🤮.
Ich fürchte, das ist etwas grösseres. 😔
Gruss Alex
da ich in meiner Workstation (Windows 11 Pro 24H2) Intel NICs habe...
Dort tauchen auf:
Dort tauchen auf:
- Intel(R) Ethernet Converged Network Adap... [5,0,1]
- Intel X550-T2
👍👍👍 👏👏👏 das ist ein sehr interessanter Hinweis!
Sprich, somit sind von dem Problem nicht nur die Server betroffen, sondern auch die Clients, die W11 haben wiederum aber auch den gleichen Kernel wie die Server verbaut. 🙃
Ich habe soeben auf der Workstation meines Kollegen nachgesehen, welche mit W11 24H2 Enterprise und CU25-03 läuft und bei dieser sind ebenfalls die Fehler mit ID 27 zu sehen.
Und jetzt kommt was total wirres, denn die Meldungen betreffen nicht nur die NIC, sprich, die I219-V die auch wirklich online ist, sondern auch die beiden Ports der in dieser Workstation verbauten X540 ...
... die jedoch keinen Uplink haben und somit auch nicht wirklich die Netzwerkverbindung verlieren können.
Ja, ich weiss ... 😖😵💫🙊🙈
Ohh, es wird noch gruseliger, schau mal was auf dieser Workstation für Treiber installiert sind ...
... und das obwohl ...
... 🤮🤮🤮.
Ich fürchte, das ist etwas grösseres. 😔
Gruss Alex
Moin @dertowa,
ich habe jetzt auch bei meiner Workstation nachgeschaut (Windows 11 Ent 24H2 & CU25-02) und auf dieser sehe ich im Ereignislog keinen entsprechenden Fehler und das trotz der derselben I219-V, die auch in der anderen Workstation verbaut ist. 😵💫
Treiberstand meiner I219-V ist ...
... und ich habe in meiner Workstation auch keine X540 aber dafür eine Marvell 10G NIC verbaut.
Aber, seit einigen Monaten habe ich das Gefühl, das meine Workstation vor allem Netzwerktechnisch nicht wirklich rund läuft, da ich ständig, selbst beim Browsen sehr ungewöhnliche Verzögerungen feststellen muss. 😔
Gruss Alex
da ich in meiner Workstation (Windows 11 Pro 24H2) Intel NICs habe...
ich habe jetzt auch bei meiner Workstation nachgeschaut (Windows 11 Ent 24H2 & CU25-02) und auf dieser sehe ich im Ereignislog keinen entsprechenden Fehler und das trotz der derselben I219-V, die auch in der anderen Workstation verbaut ist. 😵💫
Treiberstand meiner I219-V ist ...
... und ich habe in meiner Workstation auch keine X540 aber dafür eine Marvell 10G NIC verbaut.
Aber, seit einigen Monaten habe ich das Gefühl, das meine Workstation vor allem Netzwerktechnisch nicht wirklich rund läuft, da ich ständig, selbst beim Browsen sehr ungewöhnliche Verzögerungen feststellen muss. 😔
Gruss Alex
Hey,
den Hinweis finde ich wiederum spannend.
Gerade auf meiner Workstation mal geschaut.
Nach manuellem Update über den Gerätemanager aus identischem ZIP-Paket von Intel (nicht neu heruntergeladen):
Kurzer Check, ob Microsoft mit dem Windows Update irgendwelche Altlasten verteilt hat, aber nein, es gab dort auf meiner Workstation keine Treiber Updates für Intel.
Grüße
ToWa
1
Moin @dertowa,
na ja, ich muss dasselbe auch über deinen Behaupten ...
... denn dieser ist für mich nicht minder spannend!
Denn, ich habe ein Kundensystem gefunden, welches auch auf HV22 läuft und mit CU25-03 gepatch ist und in dem auch X710 und I350er NIC verbaut sind, auf dem jedoch keine vergleichbaren Fehler zu sehen sind.
Und jetzt halte dich fest, genau auf diesem System habe ich die Treiber nicht per EXE, sonder von Hand, sprich, genau so wie du zuletzt beschrieben hast installiert. 🙃
Ähm, ich fürchte, Intel installiert per Setup/EXE wohl die falsche NDIS Version. 😬
Ich werde das gleich mal prüfen, muss aber mal davor für ne Stunde an die frische Luft um etwas runterzukommen. 😫
Gruss Alex
den Hinweis finde ich wiederum spannend.
na ja, ich muss dasselbe auch über deinen Behaupten ...
Gerade auf meiner Workstation mal geschaut.
Nach manuellem Update über den Gerätemanager aus identischem ZIP-Paket von Intel (nicht neu heruntergeladen):
Kurzer Check, ob Microsoft mit dem Windows Update irgendwelche Altlasten verteilt hat, aber nein, es gab dort auf meiner Workstation keine Treiber Updates für Intel.
Nach manuellem Update über den Gerätemanager aus identischem ZIP-Paket von Intel (nicht neu heruntergeladen):
Kurzer Check, ob Microsoft mit dem Windows Update irgendwelche Altlasten verteilt hat, aber nein, es gab dort auf meiner Workstation keine Treiber Updates für Intel.
... denn dieser ist für mich nicht minder spannend!
Denn, ich habe ein Kundensystem gefunden, welches auch auf HV22 läuft und mit CU25-03 gepatch ist und in dem auch X710 und I350er NIC verbaut sind, auf dem jedoch keine vergleichbaren Fehler zu sehen sind.
Und jetzt halte dich fest, genau auf diesem System habe ich die Treiber nicht per EXE, sonder von Hand, sprich, genau so wie du zuletzt beschrieben hast installiert. 🙃
Ähm, ich fürchte, Intel installiert per Setup/EXE wohl die falsche NDIS Version. 😬
Ich werde das gleich mal prüfen, muss aber mal davor für ne Stunde an die frische Luft um etwas runterzukommen. 😫
Gruss Alex
Moin @dertowa,
ähm, dass das Problem nur bei Intel NIC's vorkommt, können wir glaube ich knicken.
Denn ich habe bei meiner Workstation das Log mal genauer durchgesehen und dabei das folgende ...
... gefunden.
Sprich, auch NIC's anderer Hersteller sind von diesem Problem betroffen, deren entsprechende Event's, erscheinen jedoch nicht so wie bei den Intel NIC's unter ID 27, sondern unter anderen ID's. 😬😭🤮🤮
Ich bin aber noch nicht fertig ... denn diese Marvell 10G NIC bei der laut den Meldungen von Windows ständig ein Verbindungsverlust vorkommt, hat seit Monaten überhaupt keinen Link, sprich, ist nicht gepatcht. 😖😵💫
@microsoft
Wie kann denn eine NIC die überhaut keinen Link hat, den bitteschön einen "Network link lost" haben? 🤨
Und wie schon zuvor geschrieben, die in dieser Workstation auch verbaute Intel I219-V, erzeugt wiederum keine derartigen Fehler. 🙃
Treiberstand I350:
Treiberstand Marvell 10G:
Gruss Alex
Keine "akuten" Events, lustigerweise aber wenn dann immer nur Intel NICs, die für den produktiven Betrieb genutzten Broadcom 10Gs gibt es nicht in der Liste.
ähm, dass das Problem nur bei Intel NIC's vorkommt, können wir glaube ich knicken.
Denn ich habe bei meiner Workstation das Log mal genauer durchgesehen und dabei das folgende ...
... gefunden.
Sprich, auch NIC's anderer Hersteller sind von diesem Problem betroffen, deren entsprechende Event's, erscheinen jedoch nicht so wie bei den Intel NIC's unter ID 27, sondern unter anderen ID's. 😬😭🤮🤮
Ich bin aber noch nicht fertig ... denn diese Marvell 10G NIC bei der laut den Meldungen von Windows ständig ein Verbindungsverlust vorkommt, hat seit Monaten überhaupt keinen Link, sprich, ist nicht gepatcht. 😖😵💫
@microsoft
Wie kann denn eine NIC die überhaut keinen Link hat, den bitteschön einen "Network link lost" haben? 🤨
Und wie schon zuvor geschrieben, die in dieser Workstation auch verbaute Intel I219-V, erzeugt wiederum keine derartigen Fehler. 🙃
Treiberstand I350:
Treiberstand Marvell 10G:
Gruss Alex
Zitat von @MysticFoxDE:
ähm, dass das Problem nur bei Intel NIC's vorkommt, können wir glaube ich knicken.
ähm, dass das Problem nur bei Intel NIC's vorkommt, können wir glaube ich knicken.
Hey,
OK dann spiele ich mal mit und werfe die Broadcom bzw. Supermicro 10Gs (bnxtnd) in die Runde.
Hyper-V01
Das Log des zweiten Hyper-V brauche ich nicht anhängen, da ist ebenfalls nur der 21.03. vermerkt und nun kramen wir mal im Gedächtnis.
Unsere Netgear Switche haben aktuell folgende Uptime
- 19 days, 3 hrs, 34 mins, 15 secs
Ja der 28.02. ist eine Ausnahme, den habe ich aber auf Hyper-V02 nicht im Log, so weit reicht mein Gedächtnis nicht.
Für meinen Part passt das also mit einem tatsächlichen Netzwerkverlust überein.
P.S.: Bei den Intel NICs könnte es auch sein, dass da die eine oder andere nicht gesteckt ist, das müsste ich im Detail prüfen, da wären dann ggf. also wirklich Logeinträge die unsinnig sind.
Grüße
ToWa
Moin @dertowa,
😯 ... 😭 ... damit ist Intel als Einzeltäter auch wieder raus.
Sprich, der Ball geht wieder zurück Richtung Microsoft. 🙃
Ich kann einen geringen Teil der Meldungen auch plausibilisieren, sprich, einem bestimmten Ereignis zuordnen, der Grossteil dieser, mach jedoch absolut keinen Sinn.
Ja, das eine NIC die keinen Link hat theoretisch auch keinen Link verlieren kann ist eigentlich einleuchtend, so wie es aussieht, sieht Microsoft das praktisch jedoch etwas anders. 🙃
Alleine schon das beweist, dass die Microsoftianer definitiv auch Dreck am Stecken haben.
Gruss Alex
OK dann spiele ich mal mit und werfe die Broadcom bzw. Supermicro 10Gs (bnxtnd) in die Runde.
Hyper-V01
Hyper-V01
😯 ... 😭 ... damit ist Intel als Einzeltäter auch wieder raus.
Sprich, der Ball geht wieder zurück Richtung Microsoft. 🙃
Das Log des zweiten Hyper-V brauche ich nicht anhängen, da ist ebenfalls nur der 21.03. vermerkt und nun kramen wir mal im Gedächtnis.
Unsere Netgear Switche haben aktuell folgende Uptime
Unsere Netgear Switche haben aktuell folgende Uptime
- 19 days, 3 hrs, 34 mins, 15 secs
Ich kann einen geringen Teil der Meldungen auch plausibilisieren, sprich, einem bestimmten Ereignis zuordnen, der Grossteil dieser, mach jedoch absolut keinen Sinn.
P.S.: Bei den Intel NICs könnte es auch sein, dass da die eine oder andere nicht gesteckt ist, das müsste ich im Detail prüfen, da wären dann ggf. also wirklich Logeinträge die unsinnig sind.
Ja, das eine NIC die keinen Link hat theoretisch auch keinen Link verlieren kann ist eigentlich einleuchtend, so wie es aussieht, sieht Microsoft das praktisch jedoch etwas anders. 🙃
Alleine schon das beweist, dass die Microsoftianer definitiv auch Dreck am Stecken haben.
Gruss Alex
Tritt der oder treten die Fehler eventuell an allen NICs auf wenn ein Intel Treiber und eine aktive Intel NIC vorhanden sind?
Moin @ukulele-7,
die oben angesprochenen Fehler, treten leider sowohl bei Fehlern/Problemen auf, aber auch bei absolut unsinnigen Ereignissen ...
Windows 11 24H2 - CU25-04 - Tagebuch - Tag 1
... und sind daher nicht wirklich sehr aussagekräftig, respektive, nicht wirklich gut geeignet um einen Fehler zu finden/lokalisieren. 😔
Ferner haben wir das Cluster des Kunden wieder stabil bekommen ... dazu mussten wir jedoch bei allen VM's SR-IOV deaktivieren. 😭🤢🤮
Denn so wie es aussieht, läuft SR-IOV in Verbindung mit Snapshots/Migrationen alles andere als Stabil. 😔
Daher wahrscheinlich auch die Probleme bei Veeam.
Zu deiner ursprünglichen Frage, nein ich kann die Probleme momentan nicht wirklich nur auf Intel eingrenzen und Microsoft hat hier definitiv auch was verbockt.
Wenn ich heute dazukomme, dann setze ich in unserem Test-Lab mal ein paar VM's mit SR-IOV vNIC's auf und schau mir mal genauer an, was mit diesen bei Snapshots passiert oder sie mit Veeam gesichert werden.
Gruss Alex
Tritt der oder treten die Fehler eventuell an allen NICs auf wenn ein Intel Treiber und eine aktive Intel NIC vorhanden sind?
die oben angesprochenen Fehler, treten leider sowohl bei Fehlern/Problemen auf, aber auch bei absolut unsinnigen Ereignissen ...
Windows 11 24H2 - CU25-04 - Tagebuch - Tag 1
... und sind daher nicht wirklich sehr aussagekräftig, respektive, nicht wirklich gut geeignet um einen Fehler zu finden/lokalisieren. 😔
Ferner haben wir das Cluster des Kunden wieder stabil bekommen ... dazu mussten wir jedoch bei allen VM's SR-IOV deaktivieren. 😭🤢🤮
Denn so wie es aussieht, läuft SR-IOV in Verbindung mit Snapshots/Migrationen alles andere als Stabil. 😔
Daher wahrscheinlich auch die Probleme bei Veeam.
Zu deiner ursprünglichen Frage, nein ich kann die Probleme momentan nicht wirklich nur auf Intel eingrenzen und Microsoft hat hier definitiv auch was verbockt.
Wenn ich heute dazukomme, dann setze ich in unserem Test-Lab mal ein paar VM's mit SR-IOV vNIC's auf und schau mir mal genauer an, was mit diesen bei Snapshots passiert oder sie mit Veeam gesichert werden.
Gruss Alex
Moin Zusammen,
das folgende bitte am Besten selbst ...
... auf der Zunge zergehen lassen. 😁
Und hier noch ein kleines ...
... Sahnehäubchen. 🙃
Gruss Alex
das folgende bitte am Besten selbst ...
... auf der Zunge zergehen lassen. 😁
Und hier noch ein kleines ...
... Sahnehäubchen. 🙃
Gruss Alex
