win32k.sys MEMORY_MANAGEMENT (0x1a) affecting multiple computers in the last 2 months with no clear cause

Filip Podraza | Acantha 0 Reputation points
2026-08-17T13:10:42.4033333+00:00

Hello.

Multiple Windows 11 systems entering unrecoverable BSOD loop with MEMORY_MANAGEMENT (0x1A), subtype 0x1015, MiUnloadSystemImage

I am an MSP admin with multiple customer environments and have experienced a growing number of Windows 11 systems entering an unrecoverable BSOD loop over the last few weeks.

The issue has occurred across multiple hardware platforms including:

Dell Vostro 3525

Dell Vostro 3425

Dell Inspiron 15 3525

Dell Precision 3490

HP EliteBook 840 G7

Affected devices are running Windows 11 25H2.

Symptoms:

Users typically report returning to their computer in the morning and finding:

MEMORY_MANAGEMENT (0x1A)

What failed: win32k.sys

In a constant loop, Windows tries to boot and then goes to the above error message, and then shuts down, and so on, and the loop cannot be stopped.

Recovery attempts fail, including:

Startup Repair

Safe Mode

SFC

DISM

Uninstall Updates

All Windows Recovery options

We have also tried reseating all components, battery, RAM, disk.

The only reliable recovery method found so far has been a full Windows reinstall.

Memory Dump Analysis

We collected crash dump files from two affected systems, and event viewer logs from one affected system:

Example 1:

BUGCHECK_CODE: 1a 2 BUGCHECK_P1: 1015 3 PROCESS_NAME: smss.exe 4 Failure.Bucket: 0x1a_1015_nt!MiUnloadSystemImage

Example 2:

BUGCHECK_CODE: 1a 2 BUGCHECK_P1: 1015 3 PROCESS_NAME: smss.exe 4 Failure.Bucket: 0x1a_1015_nt!MiUnloadSystemImage

One dump's Arg2 address resolves to:

win32k.sys

Version: 10.0.26100.8655

Stack trace includes:

NtSetSystemInformation 2 MmUnloadSystemImage 3 MiUnloadSystemImage 4 KeBugCheckEx

Multiple unrelated hardware platforms affected.

Issue began within a similar time period. Appears to occur overnight in several cases. Not believed to be hardware-related due to the number and variety of affected devices. Some affected devices use third party anti-virus and security software, however checking the logs of this security software it does not seem to be blocking or quarantining any files or software prior or during the issue. Some affected devices had DisplayLink software installed, but other affected devices did not, so DisplayLink is not the common denominator. Review of CBS logs does not reveal obvious component store corruption or repair failures.

Could anyone review dump and log files if I could attach them and advise whether:

There are any known issues relating to:

Windows 11 25H2 win32k.sys MEMORY_MANAGEMENT (0x1A) subtype 0x1015 MiUnloadSystemImage failures

Whether the recurring failure bucket:

0x1a_1015_nt!MiUnloadSystemImage

is associated with any known Windows defect, servicing issue, or driver compatibility issue.

Any further diagnostic data could be collected from future affected devices prior to rebuild. Log collection has been scarce due to the urgency of this issue, as there is no fix for us but to re-install a device, however due to this being a recurring pattern we have started collecting logs.

Any further information required please let me know

Windows for business | Windows Client for IT Pros | Devices and deployment | Install Windows updates, features, or roles
0 comments No comments

1 answer

Sort by: Most helpful
  1. Allan Solomon Mejia 3,840 Reputation points
    2026-08-18T02:04:50.4+00:00

    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.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.