[German]I'm going to include a post here in the blog that a blog reader described to me a few days ago. An HPE ProLiant DL325 Gen10 Plus v2 running Windows Server 2025 triggers IRQL_NOT_LESS_OR_EQUAL blue screens (stop code 0x0000000a) in ntoskrnl.exe as soon as the July 2025 updates (KB5062553 ff.) are installed. This does not appear to be an isolated case, as I have received two further reports from readers via the Internet. The cause could be incompatibilities with AMD processors, but nothing is known yet.
Reader tip about BSOD in Windows Server 2025
Blog reader Marco M. from Swiss had already contacted me in July 2025, but due to vacations and other circumstances, the issue was put on hold. He had serious issues with BSOD on Windows Server 2025, caused by July 2025 updates.
Initial situation with Windows Server 2025 on HPE servers
The initial situation involves the following HPE server models, which are operated in the reader's data center:
- ProLiant DL325 Gen10 Plus v2 with "AMD EPYC 7443P 24-core processor"
- ProLiant DL325 Gen10 with "AMD EPYC 7402P 24-core processor"
Windows Server 2025 is installed directly on the hardware on the HPE servers, so these are not virtual servers.
Everything fine until the June 2025 updates
In the initial report, the reader stated that all machines running Windows Server 2025 that had been patched up to update KB5060842 (OS Build 26100.4349) from June 10, 2025, were running smoothly and had no problems.
July 2025 updates trigger BlueScreen
After installing cumulative update KB5062553 (OS Build 26100.4652) from July 8, 2025, the server starts normally until the login screen. But then, after a few minutes, a BSOD appears with the following error message (stop code 0x0000000a):
Stop Code: IRQL_NOT_LESS_OR_EQUAL
What failed: ntoskrnl.exe
Installing the out-of-band update KB5064489 (OS Build 26100.4656) from July 13, 2025 did not change this situation – the BlueScreen continues to appear.
Reinstallation, update, and BSOD again
The blog reader then reinstalled Windows Server 2025 on a machine without configuring any parameters. The installation was successful, and the machine ran without errors. The reader then started Windows Update and reinstalled the cumulative update KB5062553 (OS Build 26100.4652) from July 8, 2025. The process ran smoothly and without errors, so the server was restarted. Shortly after the user logged in, a BlueScreen appeared again:
Stop Code: IRQL_NOT_LESS_OR_EQUAL
What failed: ntoskrnl.exe
After the July 2025 update KB5062553 at the latest, Windows Server 2025 crashes with BSOD on the above-mentioned HPE servers. This does not appear to be an isolated case.
First report on reddit.com
The blog reader wrote to me in his initial email that he had only found one article on reddit.com titled Potential Issues with Windows Server 2025 June 2025 Update that described the same problem. In the case described, Windows Server 2025 was installed on a Supermicro H12SSL-i, AMD EPYC 7313. This installation of Windows Server 2025 worked flawlessly until build 26100.1742.240906-0331.
After the user upgraded to the cumulative update from June 2025, Windows Server 2025 could no longer boot because a BSOD occurred in ntoskrnl.exe. Here, the affected party also attempted to reinstall Windows Server 2025, but again received a BSOD. At first, the affected party thought it might have something to do with an additional RAID card, Mellanox Connectx-5, or 2 x U.2 NVMe's. These were removed and reinstalled. Windows Server 2025 was installed on a Samsung PM983 M.2 NVMe.
The person affected writes that he has seen Proxmox users report a similar problem with Server 2025 VMs (see also Windows 11/Server 2025 June 2025 updates cause BSOD in Proxmox/KVM/QEMU), but nothing about bare metal installations. So far, there has been no indication of the cause in this thread, at least from what I have seen from skimming through it.
Report at Microsoft Q&A
On August 14, 2025, the blog reader contacted me again by email and pointed me to the next hit with the title After I install update KB5062553 geting BSOD – IRQL NOT LESS OR EQUAL, Windows 2025 from August 4, 2025 on Microsoft Q&A.
There is also a problem with Windows Server 2025, which triggers a BSOD with the stop code: IRQL NOT LESS OR EQUAL in ntoskrnl.exe after installing the latest update (KB5062553 from July 8, 2025). According to the person affected, this problem occurs on several computers after the update.
Here, too, it is said that reinstalling Windows Server 2025 helps and the system runs until the June 2025 update KB5062553 is installed. Then the BSOD reappears after a restart. Reinstalling the drivers and updating the BIOS did not help.
The Q&A post contains a link to a mini dump, which I viewed using Nirsoft BlueScreen Viewer. However, this does not provide any further information. A complete dump will probably need to be extracted and analyzed in Windows Debugger in order to narrow down the cause.
Report in the Thomas Krenn Wiki
After I finally posted this article online, a reader pointed me to a wiki article by Thomas Krenn on BlueSky (thanks for the tip).
An undated post titled Windows Update KB5062553 causes IRQL NOT LESS OR EQUAL it is confirmed, that on Supermicro H12 motherboards:
- Supermicro H12SSL-NT
- Supermicro H12SSL-CT
- Supermicro H12SSL-i
since installing the July 2025 updates (KB5062553, ff.), the above BSOD occurs. An unofficial workaround is to uninstall the relevant updates – but this isn't ideal, as it doesn't fix the vulnerabilities. I'll try to report the problem to Microsoft.
Root cause analysis: TPM and UEFI ruled out
Addendum: Within my German blog, some wild theories were discussed in some comments, suggesting that TPM was the root cause or that it could be related to UEFI issues. Here a few more insights.
Another test and new findings
Swiss blog reader Marco M. subsequently sent me information that he had run a new test with a "ProLiant DL325 Gen10" system with an "AMD EPYC 7402P 24-core processor" in legacy BIOS mode. Windows Server 2025 was installed in the standard desktop version from a USB stick using the following ISO file:
SW_DVD9_Win_Server_STD_CORE_2025_24H2.8_64Bit_German_DC_STD_MLF_X24-07260.ISO
The installation went smoothly, the user logged in once and left the installation "untouched." Then a restart was performed and the system waited until the latest Windows Update KB5063878 for Windows Server 2025 (OS Build 26100.4946) from August 12, 2025 was installed. The system was restarted, and the progress bar was at 30%, so everything seemed fine. The second phase of the update began, with the progress bar moving from 30% to 100%. Everything looked good until, after a few minutes, the following familiar message appeared.
The reader wrote, "This means that a BOSD is also issued in Legacy BIOS mode, which should rule out a problem with UEFI, with or without Secure Boot and TPM." In the screenshot above, Wof.sys is listed as the component causing the problem. The abbreviation stands for Windows Overlay Filter, and the sys file is a filter driver used for compressed image files in Windows (see this Microsoft Support article).
There are numerous posts on the Internet that deal with fixing BlueScreens related to the driver. However, in the current case, this leads nowhere, as the reader wrote: "Possibly a driver problem with Wof.sys? Wof.sys is output." This refers to the BlueScreen display where the driver is named. But the reader showed me the properties of the driver:
The driver is very up to date, dated July 16, 2025, and digitally signed by Microsoft. There's no point in messing around with it.
Attempt analysis with WinDbg and BlueScreen Viewer
I found a minidump in Microsoft Q&A in the post titled After I install update KB5062553 geting BSOD – IRQL NOT LESS OR EQUAL, Windows 2025 from August 4, 2025. In my old German article series Windows BlueScreen-Analyse – Teil 3 from 2012, I outlined the possibilities for analyzing dump files that generate BlueScreens.
Therefore, the mini dump mentioned above was downloaded and imported into NirSoft BlueScreen Viewer. However, it did not reveal anything beyond the above findings that ntoskrnl.exe was involved.
I then installed the Windows debugger WinDBG from the Store on a Windows 10 notebook and analyzed the mini dump there. I had stated in the German comment here that memory access to an invalid address triggers the BSOD. The output from the Windows Debugger led me to a discussion in the BSOD IRQL_NOT_LESS_OR_EQUAL thread from June 2025 during a web search.
But it didn't help, because I didn't know the boundary conditions, MsMpEng.exe was named as the cause, and I couldn't access the dump files hosted on online stores. So the suggestion from the German comment here wasn't feasible – whether it would have helped is anyone's guess.
On the one hand, I welcome the many discussions and assumptions expressed by my German blog readers. I want to make use of the collective intelligence of the readership and had hoped for the "I have that too, it's because of…" effect. Unfortunately, one problem is the "comment noise" caused by assumptions, which quickly dilute everything so that the core message is lost. An no, I don't got a clue, what's the root cause.
To summarize these discussions and assumptions, here is some concluding information. I would also evaluate a complete dump in the debugger, but I'm not sure if that would lead anywhere. However, the blog reader provided me with some additional information. In his test outlined above, with a new installation of Windows Server 2025 in Legacy BIOS mode before installing the August 2025 security update, he set the option "Complete memory dump" under "Save information" in the system settings (Control Panel, System and Security, System, Advanced System Settings, Advanced tab, "Startup and Recovery" category) under "Save information," he had set the option "Complete memory dump."
This should generate a complete memory dump when a Blue Screen occurs. The reader's information was as follows: "Although 'Complete Memory Image' was set for debugging before the KB, Windows Server 2025 does not create this memory dump file when a BSOD occurs. He only received a DumpStack.log file with the following content.
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.
But I didn't get anywhere with that either. I'll try to pass the whole thing on to Microsoft. Something is seriously broken there, so the developers should take care of it.
Similar article:
Patchday: Windows Server-Updates (June 10, 2025)
Windows 11/Server 2025 June 2025 updates cause BSOD in Proxmox/KVM/QEMU
Windows 11 24H2: Out-of-Band Update KB5063060
Windows 11 22H2 – 24H2 Preview-Updates verfügbar
Windows 10/11 and Server: Known issues (early July 2025)
