[English]Ich nehme mal einen Beitrag hier in den Blog auf, den mir ein Blog-Leser vor einigen Tagen geschildert hat. Ein HPE-ProLiant DL325 Gen10 Plus v2 mit Windows Server 2025 löst IRQL_NOT_LESS_OR_EQUAL Blue Screens (Stopp-Code 0x0000000a) in ntoskrnl.exe aus, sobald die Updates von Juli 2025 (KB5062553 ff.) installiert wurden. Es scheint kein Einzelfall zu sein, denn über den Leser habe ich zwei weitere Fundstellen im Internet bekommen. Ursache könnten Inkompatibilitäten mit den AMD-Prozessoren zu sein, aber es ist noch nichts bekannt. Ergänzung: Weitere Informationen und Analysen nachgetragen, bestimmte Annahmen ausgeschlossen.
Leserhinweis auf BSOD in Windows Server 2025
Blog-Leser Marco M. hatte mich bereits im Juli 2025 kontaktiert, durch Urlaub und andere Umstände ist das Thema liegen geblieben.
Ausgangslage mit Windows Server 2025 auf HPE-Servern
Als Ausgangslage geht es um die folgenden HPE-Server-Modelle, die im Rechenzentrum des Lesers betrieben werden:
- "ProLiant DL325 Gen10 Plus v2" mit "AMD EPYC 7443P 24-Core Processor"
- "ProLiant DL325 Gen10" mit "AMD EPYC 7402P 24-Core Processor"
Auf den HPE-Servern ist Windows Server 2025 direkt auf der Hardware installiert, es handelt sich also nicht um virtuelle Server.
Bis zu den Juni 2025-Updates alles in Ordnung
Bei der Erstmeldung hieß es vom Leser, dass alle Maschinen mit Windows Server 2025, die bis zum Update KB5060842 (OS Build 26100.4349) vom 10. Juni 2025 gepatcht waren, problemlos gelaufen seinen und keine Probleme machten.
Juli 2025-Updates lösen BlueScreen aus
Nach der Installation von des kumulativen Updates KB5062553 (OS Build 26100.4652) vom 8. Juli 2025 startet der Server normal bis zum Anmeldebildschirm. Aber dann erscheint nach ein paar Minuten ein BSOD mit folgender Fehlermeldung (Stopp-Code 0x0000000a):
Stop Code: IRQL_NOT_LESS_OR_EQUAL
What failed: ntoskrnl.exe
Auch die Installation des Out-of-Band-Updates KB5064489 (OS Build 26100.4656) vom 13. Juli 2025 änderte nichts an dieser Situation – der BlueScreen kommt weiterhin.
Neuinstallation, Update und erneut BSOD
Der Blog-Leser hat dann an einer Maschine eine Neuinstallation von Windows Server 2025 vorgenommen, ohne dieses auch nur irgendwo zu parametrisieren. Die Installation verlief erfolgreich, die Maschine lief ohne Fehler durch. Dann hat der Leser Windows Update gestartet und das kumulativen Updates KB5062553 (OS Build 26100.4652) vom 8. Juli 2025 erneut installieren lassen. Der Vorgang verlief problemlos und ohne Fehler, so dass der Server neu gestartet wurde. Kurz nach der Benutzeranmeldung wurde erneut ein BlueScreen angezeigt:
Stop Code: IRQL_NOT_LESS_OR_EQUAL
What failed: ntoskrnl.exe
Spätestens nach dem Juli 2025-Update KB5062553 kommt es unter Windows Server 2025 auf den oben genannten HPE-Servern zum Absturz mit BSOD. Es scheint kein Einzelfall zu sein.
Erste Meldung auf reddit.com
Der Blog-Leser schrieb mir in der Eingangsmail, dass er nur einen Artikel auf reddit.com mit dem Titel Potential Issues with Windows Server 2025 June 2025 Update gefunden habe, der das gleiche Problem beschreibt. Im beschriebenen Fall wurde Windows Server 2025 auf einem Supermicro H12SSL-i, AMD EPYC 7313 installiert. Diese Installation von Windows Server 2025 funktionierte bis Build 26100.1742.240906-0331 einwandfrei.
Nachdem der Nutzer ein Upgrade auf das kumulative Update vom Juni 2025 durchgeführt hat, konnte Windows Server 2025 nicht mehr booten, weil ein BSOD in ntoskrnl.exe auftrat.
Auch hier hat der Betroffene eine Neuinstallation von Windows Server 2025 versucht, aber erneut einen BSOD erhalten. Zunächst dachte der Betroffene, es könnte etwas mit einer zusätzlichen RAID-Karte, Mellanox Connectx-5 oder 2 x U.2 NVMe's zu tun haben. Diese wurden entfernt und neu installiert. Windows Server 2025 wurde auf einem Samsung PM983 M.2 NVMe installiert.
Der Betroffene schreibt, dass er gesehen habe, dass Proxmox-Benutzer ein ähnliches Problem mit Server 2025-VMs gemeldet haben (siehe auch Windows 11/Server 2025 Juni 2025-Updates verursachen BSOD in Proxmox/KVM/QEMU), aber nichts über Bare-Metal-Installationen. Bisher hat es in diesem Thread, zumindest, was ich vom querlesen gesehen habe, noch keinen Hinweis auf die Ursache gegeben.
Meldung bei Microsoft Q&A
Zum 14. August 2025 hat sich der Blog-Leser nochmals per E-Mail gemeldet und wies mich auf den nächsten Treffer mit dem Titel After I install update KB5062553 geting BSOD – IRQL NOT LESS OR EQUAL, Windows 2025 vom 4. August 2025 bei Microsoft Q&A hin.
Auch dort gibt es ein Problem mit Windows Server 2025, der nach der Installation des letzten Updates (KB5062553 vom 8. Juli 2025) einen BSOD mit dem Stop-Code: IRQL NOT LESS OR EQUAL in ntoskrnl.exe auslöst. Laut Betroffenem tritt dieses Problem nach dem Update auf mehreren Computern auf.
Auch hier heißt es, dass eine Neuinstallation von Windows Server 2025 hilft und das System solange läuft, bis das Juni 2025-Update KB5062553 installiert wird. Dann ist der BSOD nach einem Neustart wieder da. Eine Neuinstallation der Treiber und eine BIOS -Aktualisierung hat nichts gebracht.
Im Q&A-Post ist ein Mini-Dump verlinkt, den ich mir mit dem Nirsoft BlueScreen Viewer angesehen habe. Das ist aber nicht weiterführend. Es muss vermutlich ein vollständiger Dump gezogen und im Windows Debugger analysiert werden, um die Ursache einzugrenzen.
Meldung im Thomas-Krenn-Wiki
Ergänzung: Nachdem ich endlich den Beitrag hier online gestellt habe, wurde ich auf BlueSky von einem Leser auf einen Wiki-Beitrag von Thomas-Krenn hingewiesen (danke für den Hinweis).
In einem undatierten Beitrag mit dem Titel Windows Update KB5062553 causes IRQL NOT LESS OR EQUAL wird bestätigt, dass es auf Supermicro H12 Main-Boards:
- Supermicro H12SSL-NT
- Supermicro H12SSL-CT
- Supermicro H12SSL-i
seit Installation der Juli 2025-Updates (KB5062553, ff.) zu obigem BSOD kommt. Als inoffizieller Workaround wird die Deinstallation der betreffenden Updates genannt – was aber nicht so der Kracher ist, da die Schwachstellen nicht geschlossen werden. Ich versuche das Problem mal bei Microsoft einzuspeisen.
Ursachenforschung: TPM und UEFI ausgeschlossen
Ergänzung 2: Es wurden in den nachfolgenden Kommentaren ja einige wilde Theorien gewälzt, das TPM die Ursache sei oder es am UEFI hängen könnte.
Ein weiterer Test und neue Erkenntnisse
Der Leser hat mir im Nachgang noch die Information zukommen lassen, dass er einen neuen Test mit einem "ProLiant DL325 Gen10"-System mit "AMD EPYC 7402P 24-Core Processor" im Legacy BIOS Mode gefahren habe. Installiert wurde Windows Server 2025 in der Standard Desktop-Version vom USB Stick aus folgender ISO-Datei:
SW_DVD9_Win_Server_STD_CORE_2025_24H2.8_64Bit_German_DC_STD_MLF_X24-07260.ISO
Die Installation verlief ohne Probleme, der Nutzer hat sich einmal angemeldet und die Installation "jungfräulich gelassen". Dann wurde ein Neustart durchgeführt und gewartet, bis das neustes Windows Update KB5063878 für Windows Server 2025 (OS Build 26100.4946) vom 12. August 2025 installiert wurde. Das System wurde neu gestartet, die Fortschrittsanzeige lief bei 30%, soweit alles in Ordnung. Es kam die zweite Phase des Updates, in der die Fortschrittsanzeige von 30% – 100% durchlief. Sah gut aus, bis nach wendigen Minuten folgende bekannte Anzeige erschien.
Der Leser schrieb "Bedeutet, im Legacy BIOS Mode wird auch ein BOSD ausgegeben, dürfte somit ein Problem mit UEFI, mit oder ohne Secure Boot und TPM ausschließen." In obigem Screenshot wird Wof.sys als verursachende Komponente angegeben. Das Kürzel steht für Windows Overlay Filter, und die sys-Datei ist ein Filtertreiber, der für komprimierte Image-Dateien in Windows verwendet wird (siehe diesen Microsoft Supportbeitrag).
Es gibt zahlreiche Beiträge im Internet, die sich mit dem Fix von BlueScreens im Zusammenhang mit dem Treiber befassen. Läuft im aktuellen Fall aber ins Leere, da der Leser schrieb: " Eventuell ein Treiber Problem mit Wof.sys? Wof.sys wird ausgegeben." Bezieht sich auf die Anzeige des BlueScreens, wo der Treiber genannt wird. Aber der Leser hat mir die Eigenschaften des Treibers gezeigt:
Der ist mit 16. Juli 2025 sehr aktuell und digital von Microsoft signiert. Da herum zu fummeln bringt nichts.
Versuch einer Auswertung mit WinDbg und Co.
Ich habe bei Microsoft Q&A im Beitrag mit dem Titel After I install update KB5062553 geting BSOD – IRQL NOT LESS OR EQUAL, Windows 2025 vom 4. August 2025 einen Minidump gefunden. In meiner alten Artikelreihe Windows BlueScreen-Analyse – Teil 3 aus 2012 habe ich die Möglichkeiten zur Analyse von Dump-Dateien, die BlueScreens erzeugen, skizziert.
Daher wurde dieser Mini-Dump heruntergeladen und im NirSoft BlueScreen Viewer eingelesen. Brachte aber über die obigen Erkenntnisse, dass ntoskrnl.exe beteiligt sei, nichts.
Im Anschluss habe ich auf einem Windows 10 Notebook den Windows Debugger WinDBG aus dem Store installieren lassen und dort den Minidump analysiert. Ich hatte im Kommentar hier ausgeführt, dass ein Speicherzugriff auf eine ungültige Adresse den BSOD auslöst. Die Ausgaben des Windows Debuggers brachten mich bei einer Websuche genau zur Diskussion im Thread BSOD IRQL_NOT_LESS_OR_EQUAL vom Juni 2025.
Half aber nicht weiter, da ich die Randbedingungen nicht kannte, dort MsMpEng.exe als Verursacher genannt wurde und die auf Online-Stores gehosteten Dump-Dateien für mich nicht zugreifbar sind. Der Vorschlag aus dem Kommentar hier war also so nicht umsetzbar – ob es etwas gebracht hätte, steht in den Sternen.
Die vielen Diskussionen und Vermutungen, die von der Leserschaft geäußert werden, begrüße ich einerseits. Ich will ja die Schwarm-Intelligenz der Leserschaft nutzen und hatte auf den "habe ich auch, liegt an …"-Effekt gehofft. Ein gewisses Problem ist leider das "Kommentarrauschen" durch Vermutungen, die schnell alles verwässern, so dass der Kern verloren geht.
Um diese Diskussionen und Vermutungen etwas einzufangen, noch einige abschließende Informationen. Ich würde auch einen vollständigen Dump im Debugger auswerten, bin aber nicht sicher, ob es weiter führt. Aber der Blog-Leser hat mir noch eine Information geliefert. Er hatte in seinem oben skizzierten Test mit Neuinstallation von Windows Server 2025 im Legacy BIOS-Mode vor Installation des August 2025-Sicherheitsupdates in den Systemeinstellungen (Systemsteuerung, System und Sicherheit, System, Erweiterte Systemeinstellungen, Registerkarte Erweitert, Kategorie "Starten und Wiederherstellen") bei "Informationen speichern" die Option "Vollständiges Speicherabbild" eingestellt.
Damit sollte ein vollständiger Memory-Dump beim BlueScreen erzeugt werden. Die Information des Lesers lautete " Obwohl vor dem KB noch für Debug «Vollständiges Speicherabbild» eingestellt, erstellt Windows Server 2025 beim BSOD diese Memory Dump-Datei nicht. Er bekam nur eine DumpStack.log-Datei mit folgendem Inhalt.
DLOGFILE00010000DUMP= Dump stack initialized at UTC: 2025/08/16 15:19:49, local time: 2025/08/16 17:19:49. #BugCheckCode 0x00000000000000D1 #BugCheckP1 0xFFFFBB84D4140000 #BugCheckP2 0x00000000000000FF #BugCheckP3 0x0000000000000000 #BugCheckP4 0xFFFFF80765ED05E6 Progress 0x00000042 Elapsed BugCheck duration 00185191ms Starting get secondary dump callbacks size. Progress 0x00000052 Finish get secondary dump callbacks size. Dump Type: 5, Total Dump Size: 68556454254, Secondary Dump Size: 84334. Starting write of dump header. Finish write of dump header. Starting write of full bitmap dump header. Finish write of bitmap dump header. Starting write of memory dump data. Elapsed BugCheck duration 00185232ms Dumping physical memory to disk: 0% Dumping physical memory to disk: 5% Dumping physical memory to disk: 10% Dumping physical memory to disk: 15% Dumping physical memory to disk: 20% Dumping physical memory to disk: 25% Dumping physical memory to disk: 30% Dumping physical memory to disk: 35% Dumping physical memory to disk: 40% Dumping physical memory to disk: 45% Dumping physical memory to disk: 50% Dumping physical memory to disk: 55% Dumping physical memory to disk: 60% Dumping physical memory to disk: 65% Dumping physical memory to disk: 70% Dumping physical memory to disk: 75% Dumping physical memory to disk: 80% Dumping physical memory to disk: 85% Dumping physical memory to disk: 90% Dumping physical memory to disk: 95% Dumping physical memory to disk: 100% Finish write of bitmap dump data. Total pages:16736865 Pages written:16736865 Progress 0x00000043 Elapsed BugCheck duration 00286745ms Starting invoking secondary dump callbacks. Calling CRASHDUMP secondary callback. Return from CRASHDUMP secondary callback. Writing CRASHDUMP secondary callback data. Writing CRASHDUMP secondary callback data done. Calling USBXHCI secondary callback. Return from USBXHCI secondary callback. Writing USBXHCI secondary callback data. Writing USBXHCI secondary callback data done. Calling IoBugCheckDriverData secondary callback. Return from IoBugCheckDriverData secondary callback. Writing IoBugCheckDriverData secondary callback data. Writing IoBugCheckDriverData secondary callback data done. Calling PortDriverStandard secondary callback. Return from PortDriverStandard secondary callback. Writing PortDriverStandard secondary callback data. Writing PortDriverStandard secondary callback data done. Calling \Device\DxgKrnl secondary callback. Return from \Device\DxgKrnl secondary callback. Writing \Device\DxgKrnl secondary callback data. Writing \Device\DxgKrnl secondary callback data done. Calling Wdf01000 secondary callback. Return from Wdf01000 secondary callback. Writing Wdf01000 secondary callback data. Writing Wdf01000 secondary callback data done. Calling blackbox - CI secondary callback. Return from blackbox - CI secondary callback. Writing blackbox - CI secondary callback data. Writing blackbox - CI secondary callback data done. Calling blackbox - NTFS secondary callback. Return from blackbox - NTFS secondary callback. Writing blackbox - NTFS secondary callback data. Writing blackbox - NTFS secondary callback data done. Calling blackbox - BSD secondary callback. Return from blackbox - BSD secondary callback. Writing blackbox - BSD secondary callback data. Writing blackbox - BSD secondary callback data done. Calling secondary multi-part dump callbacks. Starting TRIAGEDUMPDATA multi-part secondary callback. Finish TRIAGEDUMPDATA multi-part secondary callback. Starting SMBiosData multi-part secondary callback. Finish SMBiosData multi-part secondary callback. Starting SMBiosRegistry multi-part secondary callback. Finish SMBiosRegistry multi-part secondary callback. Starting SMBiosRegisters multi-part secondary callback. Finish SMBiosRegisters multi-part secondary callback. Starting SMBiosDataACPI multi-part secondary callback. Finish SMBiosDataACPI multi-part secondary callback. Starting PCI multi-part secondary callback. Finish PCI multi-part secondary callback. Starting Etw multi-part secondary callback. Finish Etw multi-part secondary callback. Finish calling secondary multi-part dump callbacks. Progress 0x00000045 Finish invoking secondary dump callbacks. Starting invoking dump complete callbacks; Type: 0x04. Finished invoking dump complete callbacks; Type: 0x04. Progress 0x00000046 Dump ended at UTC: 2025/08/16 15:19:49, local time: 2025/08/16 17:19:49. Elapsed BugCheck duration 00286753ms Progress 0x00000053 Dump completed successfully.
Da bin ich aber auch nicht weitergekommen. Ich versuche das auf Englisch an Microsoft zu spülen. Irgend etwas ist da arg kaputt, sollen die Entwickler sich drum kümmern.
Ähnliche Artikel:
Patchday: Windows Server-Updates (10. Juni 2025)
Windows 11/Server 2025 Juni 2025-Updates verursachen BSOD in Proxmox/KVM/QEMU
Windows 11 24H2: Out-of-Band-Update KB5063060
Windows 11 22H2 – 24H2 Preview-Updates verfügbar
Windows 11 24H2 Juni 2025-Update-Probleme: KB5060842 mit falschem Zeitstempel und Print to PDF
Windows 10/11 und Server: Bekannte Probleme (Anfang Juli 2025)
MVP: 2013 – 2016
Wenn er 2025 fahren will muss er auf 9000er CPUs (2) schwenken, 7000er (1) unterstützt Microsoft nicht mehr. Warum 's bisher ging? Klarer Fall von 'der Krug geht zum Brunnen bis er bricht'.
_
(1) * ttps://learn.microsoft.com/en-us/troubleshoot/windows-server/setup-upgrade-and-drivers/windows-server-support-installation-for-amd-role-family-processor
(2) * ttps://learn.microsoft.com/en-us/troubleshoot/windows-server/virtualization/support-and-installation-instructions-for-amd-epyc-9004-series-server-processors
Das liest sich auf dieser MS Seite zu den Prozessor Anforderungen (aktualisiert 05/2025 und damit 4 Monate aktueller als die anderen Links) aber anders:
https://learn.microsoft.com/de-de/windows-hardware/design/minimum/windows-processor-requirements
Windows Server 2025 kompatibel sind demnach folgende AMD CPUs:
AMD EPYC 7xx2, AMD EPYC 7xx3, AMD EPYC 4xx4, AMD EPYC 4xx5, AMD EPYC 8xx4, AMD EPYC 9xx4 und AMD EPYC 9xx5
Würde sich auch damit decken, dass die Hersteller Lenovo, HP und Dell für diese Typen Treiber für Server 2025 bereitstellen
Kann ich zumindest bei DELL nicht nachvollziehen. Wo hast Du die Treiber gesehen?
AMD Epyc 7402 und 7443 werden von Windows 11 24H2 offiziell unterstützt und Server 2025 hat die selbe Codebasis wie 24H2.
*ttps//learn. microsoft. com/en-us/windows-hardware/design/minimum/supported/windows-11-24h2-supported-amd-processors
Laut den "Windows Processor Requirements" vom 1.11.2024 sind die CPUs kompatibel mit Windows Server 2025:
AMD EPYC 7xx2, AMD EPYC 7xx3, AMD EPYC 4xx4, AMD EPYC 4xx5, AMD EPYC 8xx4, AMD EPYC 9xx4, and AMD EPYC 9xx5
*ttps://learn. microsoft. com/en-us/windows-hardware/design/minimum/windows-processor-requirements#windows-server-processors
Die beiden Links von Peter Vorstatt sind auf den 13.1. und 15.1.2025 datiert.
Was soll sich denn von November bis Januar geändert haben, so dass die Epyc 7402 und 7443 aus dem Support für die Server 2025 rausgeflogen sind?
Welchen konkreten Befehl benutzt denn der Server 2025, den der AMD Epyc 7xxx angeblich nicht kann?
Server 2025 benutzt offiziell nur den x86-x64-v2 Befehlssatz und den kann der AMD Epyc 7xxx.
Support-Ticket bei Microsoft aufmachen und einen Bugfix verlangen oder Bezahlung an Microsoft beenden.
Im Moment geht es darum, die losen Fäden erst einmal zusammen zu fügen. Irgend etwas ist mit dem Update kaputt gegangen, aber was? Microsoft ist auf jeden Fall in der Pflicht – und sobald der englische Beitrag online ist, werde ich versuchen, das dort über meine Kanäle einzuspeisen (ist schwierig, ich kann kein Support-Ticket aufmachen).
Lieber Bolko, ich schätze die Akribie Deiner Beiträge und Dein Engagement. Aber manche Dinge stellst Du Dir dann vielleicht doch zu einfach vor.
Mit der rhetorischen Frage "Welchen konkreten Befehl benutzt denn der Server 2025, den der AMD Epyc 7xxx angeblich nicht kann? insinuierst Du selbstbewusst, es gäbe keine Unterschiede zwischen den Instruction Sets. Hast Du die Punkt für Punkt tatsächlich verglichen?
Du schreibst "selbe Codebasis wie 24H2.". Auch hier: Woher weisst Du das, hast Du Quellcodeeinblick und hinreichende Vergleiche angestellt?
Betr. "Die beiden Links von Peter Vorstatt sind auf den 13.1. und 15.1.2025 datiert.": Zu letzterem Datum: Aber nur gemäss gerendertem Text. Im Quelltext erscheint updated_at 2025-02-21T10:01:00Z und dann gibt es noch einen Datumstempel "July 14, 2025 at 08:54:06 GMT+2" der 'irgendwo' in den http-Headern steht.
Betr. "Bugfix verlangen oder Bezahlung an Microsoft beenden.": Weisst Du vermutlich selbst: Entbehrt jeglicher Rechtsgrundlage und ist Traumtänzerei.
Nur kurz angeschnitten: Die Hardwarezertifizierungen, die Microsoft mit den Herstellern/OEM durchführt, werden unterschätzt/verkannt. Es gibt abseits hemdsärmliger Interpretationen keine offiziellen Aussagen des Musters 'CPU X wird unter Windows Y unterstützt' ohne gleichzeitigen und spielentscheidenden Hinweis auf Abhängigkeit von Motherboards, Firmware Revisionsständen, BIOS Konfigurationen bzw BIOS Feature Sets.
Nichts für ungut.
Also ich würde jetzt – gleiche Codebasis hin oder her – mal ein aktuelles Win 11 auf so ner Maschine testen. Müsste sich ja gleich verhalten, aber damit schließe ich schonmal aus, dasses was Server 2025 spezifisches ist.
Dann gabs da doch die Sache mit der AMD TPM-Problematik:
https://www.golem.de/news/fix-nicht-ausgeliefert-amd-kritisiert-mainboard-hersteller-fuer-umgang-mit-tpm-bug-2507-197912.html
Sind die betroffenen Server da vielleicht nicht aktuell und MS hat irgendeine TPM-abhängige Funktion eingebaut? War jedenfalls so mein erster Gedanke, weil es nur auf AMD auftritt.
1 +
Für den "ProLiant DL325 Gen10" gibt es seit dem 28.März 2025 ein Bios-Update Version 3.50_03-21-202 von HP. (*1)
Für den "ProLiant DL325 Gen10 Plus v2" gibt es seit dem 16.Mai 2025 ein Bios-Update Version 3.72_05-16-202 von HP. (*2)
Das könnte Probleme mit TPM beheben.
Wurde das bereits installiert?
(*1):
*ttps://support. hpe. com/connect/s/product?language=de&kmpmoid=1010868976&tab=driversAndSoftware&cep=on&driversAndSoftwareFilter=8000012
(*2):
*ttps://support. hpe. com/connect/s/product?language=de&kmpmoid=1013291330&tab=driversAndSoftware&cep=on&driversAndSoftwareFilter=8000012
Erlaube mir hier noch einen Hinweis. Der "ProLiant DL325 Gen10" Server besitzt kein TPM Chip, im Gegensatz zum "ProLiant DL325 Gen10 Plus v2". Für beide Server Typen gibt es seitens HPE Unterstützung in Sachen Treiber für Windows Server 2025, die sogar identisch sind. https://support.hpe.com/connect/s/product?language=de&cep=on&kmpmoid=1010868976&tab=driversAndSoftware&driversAndSoftwareFilter=8000113 & https://support.hpe.com/connect/s/product?language=de&cep=on&kmpmoid=1013291330&tab=driversAndSoftware .Windows Server Versionen setzten auch keine Unterstützung für Secure Boot und TPM voraus, im Gegensatz zu Windows 11 24H2 (kann bisher mit setup.exe /product server aber umgangen werden). Da es ja nun auch andere Systeme mit unterschiedlichen Mainboards Herstellern betrifft die AMD Prozessoren unterstützten, sehe ich die Ursache im Code ab dem KB5062553 (OS Build 26100.4652).
Erst einmal danke für deinen Input und die vielen Ratschläge. Wie oben beschrieben, es geht darum, Fäden zusammen zu ziehen.
Da es sich beim Thema um Windows Server 2025 handelt, gehe ich davon aus, dass Blog-Leser Marco M. und die Leute von Thomas Krenn, die Rechenzentren betreiben, durchaus a priori Sachen wie BIOS-Updates (bei mehreren betroffenen Systemen schon als Ursache schwierig, imho) geprüft und einiges getestet haben.
Es gilt aufzupassen, dass hier vor lauter Kommentarrauschen "die Bäume im Wald unsichtbar werden". Interessant wären Fälle, wo jemand einen vollständigen Dump (und keinen Mini-Dump) des BSOD über die Cloud bereitstellen kann – oder sogar eine konkrete Ursache auf Grund einer Dump-Analyse mit dem Debugger angeben kann. Am Trace des Mini-Dumps lässt sich für mich die Aufrufkette im Kerneltreiber nicht nachvollziehen. Hab extra mal den Windows Debugger aus dem Store auf einem Win 10-System installiert und die .dmp-Datei analysiert.
Betr. "Interessant wären Fälle, wo jemand einen vollständigen Dump (und keinen Mini-Dump) des BSOD über die Cloud bereitstellen kann – oder sogar eine konkrete Ursache auf Grund einer Dump-Analyse mit dem Debugger angeben kann.":
Sicher nützlich aber hochschwellig. Ich wundere mich, wieso niemand einmal das in der hier auch schon erwähnten Quelle (1) im dortigen Kommentar vom 11 Jun 2025, 20:50 von Forist Docs beschriebene Prozedere durchspielt.
Trotz der Fehlermeldung "What failed: ntoskrnl.exe" gehe ich davon aus, dass des Pudels Kern nicht in dieser .exe sondern in einer .sys steckt.
_
(1) *ttps://learn.microsoft.com/en-ie/answers/questions/2282592/bsod-irql-not-less-or-equal
Vielleicht weil in der Quelle ntoskrnl.exe nicht vorkommt und dort der Microsoft Defender gecrasht ist?
Stimmt, ich hatte mich auf "Günter Born sagt:
15. August 2025 um 23:34 Uhr" weiter unten gestützt.
Ist aber egal; sukzessives Falsifizieren von Treibern als mögliche Ursache ist einschlägiges Vorgehen bei BSOD.
Du hattest meinen Kommentar hier gelesen? Dort ist deine Fundstelle verlinkt – ich habe es mir aber verkniffen, nach einem Full-Dump zu suchen und den in WinDBG auszuwerten, wenn ich nicht die genauen Randbedingungen kenne. Zudem sind die verlinkten URL mit dem Full-Dumps für Dritte wie mich nicht zugreifbar. Wenn mir der Blog-Leser, der mich auf den Fall hinwies, einen Full-Dump bereitstellt, würde ich nochmals WinDBG drauf loslassen (wobei mir längst die Kenntnisse für Maschinencode-Analysen fehlen – der Teil meines Lebens lag zwischen 1981 und ca. 1985).
Und Michael Bormann, mit dem ich so um 2010 solche Dumps in Dumps analysierte und mich austauschen konnte, ist vor einigen Jahren in Rente gegangen und bereits vor Jahren verstorben. Wer Feldforschung betreiben möchte, kann mit meiner alten Artikelreihe Windows BlueScreen-Analyse – Teil 3 aus 2012 starten.
Zitat:
"Der "ProLiant DL325 Gen10" Server besitzt kein TPM Chip"
—
Der eingebaute AMD EPYC 7402P hat aber fTPM und dafür braucht man ein Firmware-Update.
.
.
.
2. Zitat:
"Windows Server Versionen setzten auch keine Unterstützung für Secure Boot und TPM voraus,"
—
Laut Microsoft braucht der Server 2025 TPM 2.0 und Secure Boot.
Zitat von der Microsoft-Support-Seite für den Server 2025:
"Zusätzlich zu den spezifischen Anforderungen, die für gesicherten Kernserver beschrieben sind, müssen die folgenden Features auf Ihrer Hardware aktiviert werden:
TPM 2.0
Sicherer Start"
*ttps://learn. microsoft. com/de-de/windows-server/get-started/hardware-requirements?tabs=cpu&pivots=windows-server-2025
Vielleicht wurde bisher ein fehlendes TPM 2.0 noch toleriert, aber mit dem neuesten Update nicht mehr.
Das würde dann auch den fehlerhaften Speicherzugriff erklären, wenn versucht wird auf ein fehlendes TPM zuzugreifen.
Man könnte auch einfach bestätigen oder negieren, ob die aktuellen UEFI-Versionen installiert sind oder nicht.
Dann hätte man einen konkreten Datenpunkt, könnte diesen Bereich als Fehlerquelle erstmal ausschließen und wäre nicht mehr auf Spekulationen angewiesen.
.
.
.
3.
Es könnte auch sein, dass Microsoft jetzt einige Dateien mit der Compiler-Option zur Erzeugung von Code im Format x86-x64-v3 oder v4 compiliert that.
Dann läuft dieser Code nicht mehr auf CPUs, die nur x86-64 oder x86-x64-v2 können.
Punkt 3 würde auch erklären, warum man x86-x64-v3 oder höher in Proxmox einstellen muss, um einen Bluescreen (Unsupported processor error) im Windows 11 24H2 Gast zu vermeiden.
x86-x64 -> SSE2
x86-x64-v2 -> zusätzlich SSE3 und SSE4.2 und POPCNT
x86-x64-v3 -> zusätzlich AVX2
x86-x64-v4 -> zusätzlich AVX-512
Gerne noch zur Info, der AMD EPYC 7402P unterstützt das Ansprechen des TPM Chip, dieser befindet sich aber nicht im Prozessor selbst, sondern als dedizierter Chip auf dem Mainboard. Doch dieser Chip existiert standardmässig nicht auf dem Mainboard des "ProLiant DL325 Gen10", im Gegensatz zum "ProLiant DL325 Gen10 Plus v2". Dann gerne noch was zu Logik, warum verhält sich denn der "ProLiant DL325 Gen10 Plus v2" (mit physischem TPM Chip) identisch mit dem "ProLiant DL325 Gen10"? Die Aktivierung von TPM und Secure Boot sind keine Mindestvoraussetzungen bei der Installation eines Windows Servers 2025, die erwähnte "gesicherte Kernserver" Funktion, respektive der Betrieb als "gesicherte Kernserver" eines Windows Server 2025 ist optional und keine Voraussetzung. Die Frage würde sich dann stellen, warum ein LTSC Produkt plötzlich die Hardware System Voraussetzungen ändern würde, ist mir seit 25 Jahren nicht einmal untergekommen.
Abschliessend noch dieser Hinweis, Windows Server 2025 lässt sich auch im "Legacy BIOS" Modus installieren und problemlos betreiben (alles selbst geprüft und verifiziert), UEFI und damit TPM und Secure Boot sind definitiv keine Mindestvoraussetzung für Windows Server 2025, damit erübrigt sich die Diskussion zu TPM und Secure Boot.
Wer TPM/Secure Boot für seine oberste Unternehmensstrategie Vernagelung der Hardware durchsetzen will, greift zu Mitteln und Wegen?
Wenn man keine Ängst vor der Kommando Zeile und Assembler hat könnte man das Minidump ja mal in den Kernel Debugger zum analyslze laden und mal gucken, was der Grund für die exeception war, ein null Pointer oder ein unbekannter OP code oder…. Hat man irgendwo die Symbole installiert bekommt man vielleicht raus, welches Modul es war. Damit kann man zwar nix fixen, aber es gibt ne Idee was es war, beim nächsten Mal.
Ist ein Speicherzugriff auf eine ungültige Adresse. Ich habe den Mini-Dump im Debugger angeschaut. Ist ziemlich genau das, was hier besprochen wird – MsMpEng.exe könnte beteiligt sein.
Beim DL345 leider auch der Fall, gibt es diesbezüglich schon eine Lösung?
Ich habe noch nichts gehört – ich habe da über die mir möglichen Kanäle bei MS eingespeist, kriege aber nicht mal eine Mitteilung, ob es bearbeitet wird.
Ich habe genau das gleiche Problem mit einem DELL PowerEdge R6515 mit einer AMD EPYC 7402P CPU.
Installiere ich KB5062553 auf dem Server und führe anschließend einen Neustart durch, werden die Updates bis 30% installiert, danach startet der Server neu und stürzt mit einem Bluescreen ab.
Bluescreen-Meldung: ndis.sys
Windows Update Fehlermeldung: 0x800f0923
Das selbe Verhalten tritt nun mit dem August Update KB5063878 auf.
Installiere ich KB5063878 auf dem Server und führe anschließend einen Neustart durch, werden die Updates bis 30% installiert, danach startet der Server neu und stürzt mit einem Bluescreen ab.
Bluescreen-Meldung: IRQL_NOT_LESS_OR_EQUAL ntoskrnl.exe
Ich habe folgendes getestet, allerdings ohne Erfolg:
– sfc /scannow ausgeführt
– chkdsk ausgeführt
– DISM /Online /Cleanup-Image /RestoreHealth ausgeführt
– ESET AntiVirus deinstalliert
– Acronis Cyber Protect Backup deinstalliert
– verschiedene Netzwerktreiber Versionen (Broadcom NetXtreme Gigabit Ethernet) installiert
– RAM Test durchgeführt
Mittlerweile wurde der Server mit Windows Server 2025 neu installiert.
Selbst nach einer Neuinstallation, ohne jegliche Zusatzsoftware, stürzt der Server nach dem Installieren von KB5062553 mit einem Bluescreen ab.
TPM/Secure Boot ist in meinem Fall auf dem Server aktiviert.
Es gibt Kommentare mit dem Hinweis, dass dieses Problem mit dem September-Update gelöst wurde:
https://www.borncity.com/blog/2025/09/10/patchday-windows-server-updates-9-september-2025/#comment-229573
Danke für die Info.
Das Kumulative Update 2025-09 (KB5065426) ließ sich nun auf dem DELL PowerEdge R6515 ohne Probleme installieren.