![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(259.20000000000005, 99%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPB%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 33%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDV%3C/text%3E%3C/svg%3E)
Hello Patrick Burns,
Based on the dump analysis you shared, the crashes are consistently pointing to network-related drivers. The two modules that stand out are e1d.sys (Intel Ethernet driver) and rtu53cx22x64.sys (Realtek wireless driver). The bugcheck code 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL indicates that these drivers are attempting to access invalid memory at elevated IRQL, which is a classic driver defect rather than a core OS fault. The fact that this started immediately after upgrading to 25H2 strongly suggests a driver compatibility regression with the new kernel build.
The Intel driver e1d.sys you have is timestamped July 2024, and the Realtek driver is June 2025. Both are older than the 25H2 kernel release (build 26100). Microsoft’s inbox drivers for Intel and Realtek NICs are often behind vendor releases, and when the kernel changes, outdated drivers can cause IRQL violations. Updating “some” machines is not enough here; you need to ensure every affected endpoint is running the latest WHQL-certified drivers directly from Intel and Realtek, not just what Windows Update provides. For Intel, download the latest PROSet/Wireless and Ethernet Adapter package from Intel’s support site, and for Realtek, obtain the current driver package from Realtek or the OEM vendor.
If you already tested with updated drivers and the issue persists, the next step is to confirm whether Hyper-V or virtualization-based security (VBS) is enabled. Your dump shows Hypervisor flags active, which means the system is running with Hyper-V enlightenments. Some NIC drivers are not stable under VBS/Hyper-V contexts in 25H2. Try disabling VBS temporarily (Device Guard and Credential Guard policies) to see if stability improves.
Another point to check is whether the machines are running with any third-party endpoint security or VPN clients. These often install filter drivers on the network stack, which can conflict with NIC drivers after a major OS update. Run fltmc filters and sc query type= driver to identify non-Microsoft drivers in the networking path. If you see additional filter drivers, update or temporarily remove them to isolate the cause.
In short, the root cause is driver incompatibility with the 25H2 kernel. The immediate remediation is to deploy the latest Intel and Realtek drivers across all endpoints, and if instability continues, disable VBS temporarily and audit for third-party network filter drivers. If the crashes persist even with current drivers and no filters, then this is a regression that needs to be escalated to Microsoft via a support case, as only they can provide a hotfix for the kernel-driver interaction.
I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!
Domic Vo.