Hello @Filip Podraza | Acantha
The consistency across unrelated hardware is significant here. Both dumps show BugCheck 0x1A with parameter 1 = 0x1015, the same nt!MiUnloadSystemImage failure bucket, and smss.exe as the active process. One dump also resolves the affected image to win32k.sys version 10.0.26100.8655.
Microsoft defines 0x1A MEMORY_MANAGEMENT as a severe memory-management error, but the module displayed on the BSOD isn't necessarily the component that originally corrupted memory. win32k.sys may therefore be where the corruption is detected during image unloading rather than the actual cause.
Since you've reproduced the same signature on Dell and HP systems and the machines fail at about the same point, I wouldn't treat RAM as the primary suspect yet. I would focus on finding a common software/servicing or kernel-driver component.
For the next affected machine, before rebuilding it, preserve at least:
C:\Windows\MEMORY.DMP
*C:\Windows\Minidump*
*C:\Windows\Logs\CBS*
*C:\Windows\Logs\DISM*
*C:\Windows\System32\winevt\Logs*
Then open the dump in WinDbg and start with:
!analyze -v
lmvm win32k
lm t n
!blackboxbsd
!blackboxntfs
!blackboxpnp
Microsoft specifically recommends !analyze for determining the exact 0x1A condition, and WinDbg can analyze both kernel and minidump files.
I would also compare the affected systems for common filter/kernel drivers, especially endpoint security/EDR, DLP, graphics/display components, remote-control agents, backup software, and other software that installs filesystem or kernel filters. The fact that some systems have DisplayLink and others don't already makes DisplayLink alone a less convincing common cause.
Driver Verifier can help identify a driver corrupting kernel memory, but I'd use it only on a test/reproducible machine, not broadly across customer production endpoints. Microsoft specifically documents Driver Verifier as a debugging mechanism for catching faulty drivers and memory corruption.
One additional point: I couldn't find Microsoft documentation currently identifying 0x1A_1015_nt!MiUnloadSystemImage with win32k.sys on Windows 11 25H2 as a confirmed known issue, nor a documented KB specifically fixing this signature. So I wouldn't state yet that this is a Windows defect.
However, with multiple unrelated machines producing essentially the same failure bucket and OS build, this is strong enough to justify opening a Microsoft support case and submitting the complete dumps. Two or more full dumps showing the same 0x1a_1015_nt!MiUnloadSystemImage signature will be considerably more useful than the BSOD screen itself.
Sharing these references with you:
Microsoft – Bug Check 0x1A: MEMORY_MANAGEMENT
Microsoft – Open a crash dump with WinDbg
Microsoft – Read small memory dump files
Please "Accept the Answer" if this information helped you. This will help us and others in the community.