24H2 BSOD With Error "MEMORY_MANAGEMENT (1a)"

I upgraded to Windows 11 24H2, and now my custom driver consistently causes a BSOD with the error code "MEMORY_MANAGEMENT (1a)".

Before the 24H2 update, my driver was functioning perfectly under the same conditions in previous versions of Windows 11, so I believe this issue is related to the 24H2 update.

I did some research and found that many third-party drivers are experiencing similar issues (for example, Voicemeeter). Some claim to have resolved the problem. Does this mean it can be fixed without intervention from Microsoft?

I would like to know if other developers have encountered this issue and how I might modify my driver to ensure compatibility with the 24H2 update.

Analysis output:

!analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

MEMORY_MANAGEMENT (1a)
    # Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000008840, The subtype of the BugCheck.
Arg2: ffffe08009580470
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:
------------------

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 4921

    Key  : Analysis.Elapsed.mSec
    Value: 15314

    Key  : Analysis.IO.Other.Mb
    Value: 7

    Key  : Analysis.IO.Read.Mb
    Value: 1

    Key  : Analysis.IO.Write.Mb
    Value: 19

    Key  : Analysis.Init.CPU.mSec
    Value: 12531

    Key  : Analysis.Init.Elapsed.mSec
    Value: 1124145

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 112

    Key  : Analysis.Version.DbgEng
    Value: 10.0.27725.1000

    Key  : Analysis.Version.Description
    Value: 10.2408.27.01 amd64fre

    Key  : Analysis.Version.Ext
    Value: 1.2408.27.1

    Key  : Bugcheck.Code.KiBugCheckData
    Value: 0x1a

    Key  : Bugcheck.Code.LegacyAPI
    Value: 0x1a

    Key  : Bugcheck.Code.TargetModel
    Value: 0x1a

    Key  : Failure.Bucket
    Value: 0x1a_8840_nt!MiGatherMappedPages

    Key  : Failure.Hash
    Value: {ce81522f-ddd8-3aad-df97-e3c05850ee58}

    Key  : Hypervisor.Enlightenments.ValueHex
    Value: 7417df84

    Key  : Hypervisor.Flags.AnyHypervisorPresent
    Value: 1

    Key  : Hypervisor.Flags.ApicEnlightened
    Value: 0

    Key  : Hypervisor.Flags.ApicVirtualizationAvailable
    Value: 1

    Key  : Hypervisor.Flags.AsyncMemoryHint
    Value: 0

    Key  : Hypervisor.Flags.CoreSchedulerRequested
    Value: 0

    Key  : Hypervisor.Flags.CpuManager
    Value: 1

    Key  : Hypervisor.Flags.DeprecateAutoEoi
    Value: 1

    Key  : Hypervisor.Flags.DynamicCpuDisabled
    Value: 1

    Key  : Hypervisor.Flags.Epf
    Value: 0

    Key  : Hypervisor.Flags.ExtendedProcessorMasks
    Value: 1

    Key  : Hypervisor.Flags.HardwareMbecAvailable
    Value: 1

    Key  : Hypervisor.Flags.MaxBankNumber
    Value: 0

    Key  : Hypervisor.Flags.MemoryZeroingControl
    Value: 0

    Key  : Hypervisor.Flags.NoExtendedRangeFlush
    Value: 0

    Key  : Hypervisor.Flags.NoNonArchCoreSharing
    Value: 1

    Key  : Hypervisor.Flags.Phase0InitDone
    Value: 1

    Key  : Hypervisor.Flags.PowerSchedulerQos
    Value: 0

    Key  : Hypervisor.Flags.RootScheduler
    Value: 0

    Key  : Hypervisor.Flags.SynicAvailable
    Value: 1

    Key  : Hypervisor.Flags.UseQpcBias
    Value: 0

    Key  : Hypervisor.Flags.Value
    Value: 55185662

    Key  : Hypervisor.Flags.ValueHex
    Value: 34a10fe

    Key  : Hypervisor.Flags.VpAssistPage
    Value: 1

    Key  : Hypervisor.Flags.VsmAvailable
    Value: 1

    Key  : Hypervisor.RootFlags.AccessStats
    Value: 1

    Key  : Hypervisor.RootFlags.CrashdumpEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.CreateVirtualProcessor
    Value: 1

    Key  : Hypervisor.RootFlags.DisableHyperthreading
    Value: 0

    Key  : Hypervisor.RootFlags.HostTimelineSync
    Value: 1

    Key  : Hypervisor.RootFlags.HypervisorDebuggingEnabled
    Value: 0

    Key  : Hypervisor.RootFlags.IsHyperV
    Value: 1

    Key  : Hypervisor.RootFlags.LivedumpEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.MapDeviceInterrupt
    Value: 1

    Key  : Hypervisor.RootFlags.MceEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.Nested
    Value: 0

    Key  : Hypervisor.RootFlags.StartLogicalProcessor
    Value: 1

    Key  : Hypervisor.RootFlags.Value
    Value: 1015

    Key  : Hypervisor.RootFlags.ValueHex
    Value: 3f7

    Key  : SecureKernel.HalpHvciEnabled
    Value: 1

    Key  : WER.OS.Branch
    Value: ge_release

    Key  : WER.OS.Version
    Value: 10.0.26100.1


BUGCHECK_CODE:  1a

BUGCHECK_P1: 8840

BUGCHECK_P2: ffffe08009580470

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD:  ffffbf0a087f4040

PROCESS_NAME:  System

STACK_TEXT:  
fffffe89`65fb1d38 fffff803`e956eeb2     : fffffe89`65fb1db8 00000000`00000001 00000000`00000100 fffff803`e9690701 : nt!DbgBreakPointWithStatus
fffffe89`65fb1d40 fffff803`e956e3dc     : 00000000`00000003 fffffe89`65fb1ea0 fffff803`e9690880 00000000`0000001a : nt!KiBugCheckDebugBreak+0x12
fffffe89`65fb1da0 fffff803`e94b88e7     : ffff38b6`c69e5938 fffff803`e9e38600 ffffbf0a`29eb1800 00000000`00001708 : nt!KeBugCheck2+0xb2c
fffffe89`65fb2530 fffff803`e96a9ec7     : 00000000`0000001a 00000000`00008840 ffffe080`09580470 00000000`00000000 : nt!KeBugCheckEx+0x107
fffffe89`65fb2570 fffff803`e931d711     : fffff803`e9e38600 fffff803`00000000 ffffbf0a`087f4040 00000000`00000001 : nt!MiGatherMappedPages+0x38c5fb
fffffe89`65fb2640 fffff803`e945652a     : ffffbf0a`087f4040 ffffbf0a`087f4040 00000000`00000080 fffff803`e931d510 : nt!MiMappedPageWriter+0x201
fffffe89`65fb2b30 fffff803`e9677d24     : fffff803`76890180 ffffbf0a`087f4040 fffff803`e94564d0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffffe89`65fb2b80 00000000`00000000     : fffffe89`65fb3000 fffffe89`65fac000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34


SYMBOL_NAME:  nt!MiGatherMappedPages+38c5fb

MODULE_NAME: nt

STACK_COMMAND:  .process /r /p 0xffffbf0a084c8040; .thread 0xffffbf0a087f4040 ; kb

IMAGE_NAME:  ntkrnlmp.exe

BUCKET_ID_FUNC_OFFSET:  38c5fb

FAILURE_BUCKET_ID:  0x1a_8840_nt!MiGatherMappedPages

OS_VERSION:  10.0.26100.1

BUILDLAB_STR:  ge_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {ce81522f-ddd8-3aad-df97-e3c05850ee58}

Followup:     MachineOwner

What does your driver do?

My driver implementation is similar to a virtual file system, and I will modify the data read by IO according to my needs. For write operations, I will only record which files are dirty.

I've decompiled part of nt!MiGatherMappedPages() code:

OriginalPte = Pfn->OriginalPte;
...
ControlAreaPtr = (_CONTROL_AREA **)(OriginalPte >> 16);
ControlArea = *ControlAreaPtr;
ControlAreaFlags = (*Section)->u.LongFlags;
if ((ControlAreaFlags & 0x20) != 0) // ControlArea->u.Flags.Image != 0
{
        ...
	if ((ControlArea->u.LongFlags & 0x800) == 0 // ControlArea->u.Flags.ImageControlAreaOnRemovableMedia == 0
	    && (Pfn->OriginalPte.Protection & MM_COPY_ON_WRITE_MASK) != MM_COPY_ON_WRITE_MASK &&
	    ((Pfn->OriginalPte.Protection & MM_PROTECTION_WRITE_MASK) == 0)
	{
		KeBugCheckEx(0x1Au, 0x8840uLL, (ULONG_PTR)Pfn, 0LL, 0LL);
	}
	...
	Pfn->OriginalPte = MiMakeDemandZeroPte(...);
	MiDereferenceControlAreaPfnList(ControlArea, 0LL, 1LL, 3);
	...
}

Looks like write protection for image-mapped pages.
I don't know how your driver can violate this invariant. Can you provide a BSOD dump?

3 Likes

Thank you for your attention. I am considering rolling back version 24H2 to an earlier version, and the issue has been resolved.

Before the rollback, I reproduced the issue multiple times, and the coredumps were almost identical. Here is the download link for the coredump (486 MB compressed, 2.68 GB uncompressed): https://drive.google.com/file/d/1qWCR0cBj_-CGwSVpBGa3fypEOKB84ekV/view?usp=sharing

I have some users who also use my driver, and they might upgrade to 24H2 in the future, so I need to be prepared for that.

Additionally, I would like to understand what exactly caused the issue. Could it be that there are certain design flaws in my driver?

It looks like you're doing some illegal tricks with the image section in your VFS.

> !pfn ffff9a800b616a80
    PFN 003CB238 at address FFFF9A800B616A80
    flink       00000000  blink / share count 00000000  pteaddress FFFFA702DB4835F0
    reference count 0000    used entry count  00A0      Cached    color 0   Priority 5
    restore pte E007561D34A00420  containing page 2EF6EE  Modified   MP     
    Modified Shared

> !pte ffff9a800b616a80+0x10 1  // Pfn->OriginalPte
                                           VA ffff9a800b616a90
PXE at FFFF9A800B616A90    PPE at FFFF9A800B616A90    PDE at FFFF9A800B616A90    PTE at FFFF9A800B616A90
contains E007561D34A00420
contains E007561D34A00420
not valid
 Subsection: FFFFE007561D34A0
 Protect: 1 - Readonly

Physical page of image section has been modified, but none of the subsections can be legally modified "in-place" - only ReadOnly (1), ExecuteRead (3) and ReadWriteCopy( 5) protections are used:

> dt _SUBSECTION FFFFE007561D34A0
nt!_SUBSECTION
   +0x000 ControlArea      : 0xffffe007`561d3420 _CONTROL_AREA
   +0x008 SubsectionBase   : 0xffffa702`db4835f0 _MMPTE
   +0x010 NextSubsection   : 0xffffe007`561d34d8 _SUBSECTION
   +0x018 GlobalPerSessionHead : _RTL_AVL_TREE
   +0x018 CreationWaitList : (null) 
   +0x020 SubsectionFlags  : _MMSUBSECTION_FLAGS
   +0x024 StartingSector   : 0
   +0x028 NumberOfFullSectors : 2
   +0x02c PtesInSubsection : 1
   +0x030 u1               : <unnamed-tag>
   +0x034 UnusedPtes       : 0y000000000000000000000000000000 (0)
   +0x034 ExtentQueryNeeded : 0y0
   +0x034 Spare            : 0y0

 !ca 0xffffe007`561d3420

ControlArea  @ ffffe007561d3420
  Segment      ffffa7031439b160  Flink      ffffe00775263518  Blink        ffffe007752717c8
  Section Ref                 0  Pfn Ref                  9d  Mapped Views                0
  User Ref                    0  WaitForDel                0  Flush Count                 0
  File Object  ffffe00779759840  PartitionId                0  
  Flags (100000a0) Image File OnUnusedList 

      \Engine\Binaries\Win64\UnrealTraceServer.exe

Segment @ ffffa7031439b160
  ControlArea       ffffe007561d3420  BasedAddress  00007ff64f260000
  Total Ptes                      9f
  Segment Size                 9f000  Committed                    0
  Image Commit                     5  Image Info    ffffa7031439b1a8
  ProtoPtes         ffffa702db4835f0
  Flags (14270000) ProtectionMask 

Subsection 1 @ ffffe007561d34a0
  ControlArea  ffffe007561d3420  Starting Sector        0  Number Of Sectors    2
  Base Pte     ffffa702db4835f0  Ptes In Subsect        1  Unused Ptes          0
  Flags                       2  Sector Offset          0  Protection           1

Subsection 2 @ ffffe007561d34d8
  ControlArea  ffffe007561d3420  Starting Sector        2  Number Of Sectors  353
  Base Pte     ffffa702db4835f8  Ptes In Subsect       6b  Unused Ptes          0
  Flags                       6  Sector Offset          0  Protection           3

Subsection 3 @ ffffe007561d3510
  ControlArea  ffffe007561d3420  Starting Sector      355  Number Of Sectors   fc
  Base Pte     ffffa702db483950  Ptes In Subsect       20  Unused Ptes          0
  Flags                       2  Sector Offset          0  Protection           1

Subsection 4 @ ffffe007561d3548
  ControlArea  ffffe007561d3420  Starting Sector      451  Number Of Sectors   15
  Base Pte     ffffa702db483a50  Ptes In Subsect        5  Unused Ptes          0
  Flags                       a  Sector Offset          0  Protection           5

Subsection 5 @ ffffe007561d3580
  ControlArea  ffffe007561d3420  Starting Sector      466  Number Of Sectors   2b
  Base Pte     ffffa702db483a78  Ptes In Subsect        6  Unused Ptes          0
  Flags                       2  Sector Offset          0  Protection           1

Subsection 6 @ ffffe007561d35b8
  ControlArea  ffffe007561d3420  Starting Sector      491  Number Of Sectors    1
  Base Pte     ffffa702db483aa8  Ptes In Subsect        1  Unused Ptes          0
  Flags                       2  Sector Offset          0  Protection           1

Subsection 7 @ ffffe007561d35f0
  ControlArea  ffffe007561d3420  Starting Sector      492  Number Of Sectors   29
  Base Pte     ffffa702db483ab0  Ptes In Subsect        6  Unused Ptes          0
  Flags                       2  Sector Offset          0  Protection           1

Subsection 8 @ ffffe007561d3628
  ControlArea  ffffe007561d3420  Starting Sector      4bb  Number Of Sectors    7
  Base Pte     ffffa702db483ae0  Ptes In Subsect        1  Unused Ptes          0
  Flags                       2  Sector Offset          0  Protection           1

P.S. I see that there is a data section for the same file:

> !ca 0xffffe007`752717c0

ControlArea  @ ffffe007752717c0
  Segment      ffffa703130e6b10  Flink      ffffe007561d3428  Blink        ffffe00775271898
  Section Ref                 0  Pfn Ref                  9d  Mapped Views                0
  User Ref                    0  WaitForDel                0  Flush Count                 0
  File Object  ffffe00779759840  ModWriteCount             0  System Views                0
  WritableRefs                0  PartitionId                0  
  Flags (10000080) File OnUnusedList 

      \Engine\Binaries\Win64\UnrealTraceServer.exe

Segment @ ffffa703130e6b10
  ControlArea       ffffe007752717c0  ExtendInfo    0000000000000000
  Total Ptes                      9d
  Segment Size                 9c3d0  Committed                    0
  Flags (60000) ProtectionMask 

Subsection 1 @ ffffe00775271840
  ControlArea  ffffe007752717c0  Starting Sector        0  Number Of Sectors   9c
  Base Pte     ffffa702f3806010  Ptes In Subsect       9d  Unused Ptes          0
  Flags                3d08000d  Sector Offset        3d0  Protection           6
  Accessed 
  Flink        ffffe007752717c8  Blink   ffffe00766e99908  MappedViews          0

Normally modified pages should be flushed when creating an image section.

2 Likes

Thank you very much for your professional analysis.

I have a general idea of where the issue lies with my driver. In the PreRead callback, I wanted to redirect read operations to another file, but my handling of paging I/O might be inappropriate.

// Get read buffer.
status = FltLockUserBuffer(Cbd);
if (!NT_SUCCESS(status)) {
    LOG_ERROR("Error(0x%08x) lock user buffer failed, fast io: %d, minior irp: 0x%08x",
              status, 
              FLT_IS_FASTIO_OPERATION(Cbd),
              Cbd->Iopb->MinorFunction);
    goto Cleanup;
} else {
    if (Cbd->Iopb->Parameters.Read.MdlAddress != NULL) {
        readBuffer = MmGetSystemAddressForMdlSafe(Cbd->Iopb->Parameters.Read.MdlAddress, NormalPagePriority | MdlMappingNoExecute);
        if (NULL == readBuffer) {
            LOG_ERROR("Error(0x%08x) get system address from MDL failed", status);
            goto Cleanup;
        }
        RtlZeroMemory(readBuffer, readLength); // Write readonly buffer here?
    } else {
        readBuffer = Cbd->Iopb->Parameters.Read.ReadBuffer;
    }
}

......

// Redirect read operation to the target file.
status = FltReadFile(Cbd->Iopb->TargetInstance,
                     Globals.TargetFileObject,
                     &Cbd->Iopb->Parameters.Read.ByteOffset,
                     readLength,
                     readBuffer,
                     FLTFL_IO_OPERATION_DO_NOT_UPDATE_BYTE_OFFSET,
                     &copyReadSize,
                     NULL,
                     NULL);
if (!NT_SUCCESS(status) && status != STATUS_END_OF_FILE) {
    LOG_ERROR("Error(0x%08x) read chunk copy file failed", status);
    goto Cleanup;
}

Cbd->IoStatus.Information = copyReadSize;
Cbd->Iopb->TargetFileObject->CurrentByteOffset.QuadPart += copyReadSize;
Cbd->IoStatus.Status = status;

FltSetCallbackDataDirty(Cbd);
callbackStatus = FLT_PREOP_COMPLETE;

......

This may not be an appropriate solution, but it has not caused any issues in the past.

Could you provide me with some advice to help me fix this problem? I would be extremely grateful if you could.

RtlZeroMemory() doesn't write to read-only memory because MdlMappingNoWrite isn't specified.
Reading with FltReadFile() without the FLTFL_IO_OPERATION_PAGING looks strange, but is unlikely to have caused current problem.

  1. What does your driver do besides redirecting paging reads?

  2. What is meant by "record which files are dirty"?

  3. Maybe you create sections?

  4. Do you manage access sharing in CREATE callbacks?

  5. Do you interact directly with the Cc or Mm API?

  6. Do I understand correctly that we are talking about PrismFsCore.sys?

  7. Have you tried running it with the driver verifier and filter verifier?

It would be great if you could reproduce the issue and attach a full kernel dump (not only automatic/kernel bitmap file).

1 Like

Thank you very much for all your support and suggestions, which have been greatly helpful for my development.

Based on your suggestions, I have rechecked my implementation and did find some issues. I will attempt to conduct a round of fixes and tests to try to resolve the problem. If I succeed in fixing it, I will get back to you.

Thank you once again for your help. :grin: