24H2 BSOD With Error “MEMORY_MANAGEMENT (1a)”

Aditya · October 22, 2025, 9:16am

Hello All,

We have upgraded to Windows 11 24H2, and now our custom drivers consistently causes a BSOD with the error code "MEMORY_MANAGEMENT (1a)".

BUGCHECK_CODE: 1a

BUGCHECK_P1: 8840

BUGCHECK_P2: ffffc4000e8c8c60

BUGCHECK_P3: 0

BUGCHECK_P4: 0

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

The analysis output is below. We have done some analysis but could not find which module is causing the BSOD. We request your help in analyzing the shared dump file to identify the problematic code or module. Thank you very much.

8: kd> !analyze -v *

MEMORY_MANAGEMENT (1a)

Any other values for parameter 1 must be individually examined.

Arguments:
Arg1: 0000000000008840, The subtype of the BugCheck.
Arg2: ffffc4000e8c8c60
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details

KEY_VALUES_STRING: 1

Key  : Analysis.CPU.mSec
Value: 108

Key  : Analysis.Elapsed.mSec
Value: 69

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

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

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

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

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

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

Key  : Bugcheck.Code.KiBugCheckData
Value: 0x1a

Key  : Bugcheck.Code.LegacyAPI
Value: 0x1a

Key  : Dump.Attributes.AsUlong
Value: 21800

Key  : Dump.Attributes.DiagDataWrittenToHeader
Value: 1

Key  : Dump.Attributes.ErrorCode
Value: 0

Key  : Dump.Attributes.LastLine
Value: Dump completed successfully.

Key  : Dump.Attributes.ProgressPercentage
Value: 100

Key  : Failure.Bucket
Value: WRONG_SYMBOLS_X64_26100.1.amd64fre.ge_release.240331-1435_TIMESTAMP_850309-225321_D8A9F461_nt_wrong_symbols!D8A9F461144F000

Key  : Failure.Hash
Value: {1dcd88f5-eae1-cea2-c312-5c68661cbb74}

Key  : WER.OS.Branch
Value: ge_release

Key  : WER.OS.Version
Value: 10.0.26100.1

BUGCHECK_CODE: 1a

BUGCHECK_P1: 8840

BUGCHECK_P2: ffffc4000e8c8c60

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FILE_IN_CAB: MEMORY2.DMP

ADDITIONAL_DEBUG_TEXT:
You can run '.symfix; .reload' to try to fix the symbol path and load symbols.

WRONG_SYMBOLS_TIMESTAMP: d8a9f461

WRONG_SYMBOLS_SIZE: 144f000

FAULTING_MODULE: fffff80784400000 nt

DUMP_FILE_ATTRIBUTES: 0x21800

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXPNP: 1 (!blackboxpnp)

BLACKBOXWINLOGON: 1

STACK_TEXT:
fffffc88af4ea568 fffff80784adab01 : 000000000000001a 0000000000008840 ffffc4000e8c8c60 0000000000000000 : nt!KeBugCheckEx
fffffc88af4ea570 fffff8078480c965 : fffff807852389c0 fffff80700000000 ffffa182fa8de040 0000000000000002 : nt!strncpy+0x256a1
fffffc88af4ea640 fffff80784887c2a : ffffa182fa8de040 ffffa182fa8de040 0000000000000080 fffff8078480c760 : nt!IoGetTransactionParameterBlock+0x1fc5
fffffc88af4eab30 fffff80784aa0b24 : ffffd100eb790180 ffffa182fa8de040 fffff80784887bd0 0000000000000000 : nt!PsGetCurrentThreadStackBase+0x55a
fffffc88af4eab80 0000000000000000 : fffffc88af4eb000 fffffc88af4e4000 0000000000000000 0000000000000000 : nt!KeSaveStateForHibernate+0x1084

STACK_COMMAND: .cxr; .ecxr ; kb

EXCEPTION_CODE_STR: D8A9F461

EXCEPTION_STR: WRONG_SYMBOLS

PROCESS_NAME: ntoskrnl.wrong.symbols.exe

IMAGE_NAME: ntoskrnl.wrong.symbols.exe

MODULE_NAME: nt_wrong_symbols

SYMBOL_NAME: nt_wrong_symbols!D8A9F461144F000

FAILURE_BUCKET_ID: WRONG_SYMBOLS_X64_26100.1.amd64fre.ge_release.240331-1435_TIMESTAMP_850309-225321_D8A9F461_nt_wrong_symbols!D8A9F461144F000

OS_VERSION: 10.0.26100.1

BUILDLAB_STR: ge_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {1dcd88f5-eae1-cea2-c312-5c68661cbb74}

Followup: MachineOwner

8: kd> kv

Child-SP RetAddr : Args to Child : Call Site

00 fffffc88af4ea568 fffff80784adab01 : 000000000000001a 0000000000008840 ffffc4000e8c8c60 0000000000000000 : nt!KeBugCheckEx
01 fffffc88af4ea570 fffff8078480c965 : fffff807852389c0 fffff80700000000 ffffa182fa8de040 0000000000000002 : nt!strncpy+0x256a1
02 fffffc88af4ea640 fffff80784887c2a : ffffa182fa8de040 ffffa182fa8de040 0000000000000080 fffff8078480c760 : nt!IoGetTransactionParameterBlock+0x1fc5
03 fffffc88af4eab30 fffff80784aa0b24 : ffffd100eb790180 ffffa182fa8de040 fffff80784887bd0 0000000000000000 : nt!PsGetCurrentThreadStackBase+0x55a
04 fffffc88af4eab80 0000000000000000 : fffffc88af4eb000 fffffc88af4e4000 0000000000000000 0000000000000000 : nt!KeSaveStateForHibernate+0x1084

Aditya · October 22, 2025, 4:32pm

Hello All, I am sharing the output of the !analyze -v with Microsoft symbols loaded

8: kd> !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: ffffc4000e8c8c60
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:

KEY_VALUES_STRING: 1

Key  : Analysis.CPU.mSec
Value: 1827

Key  : Analysis.Elapsed.mSec
Value: 1892

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

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

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

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

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

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

Key  : Bugcheck.Code.KiBugCheckData
Value: 0x1a

Key  : Bugcheck.Code.LegacyAPI
Value: 0x1a

Key  : Dump.Attributes.AsUlong
Value: 21800

Key  : Dump.Attributes.DiagDataWrittenToHeader
Value: 1

Key  : Dump.Attributes.ErrorCode
Value: 0

Key  : Dump.Attributes.LastLine
Value: Dump completed successfully.

Key  : Dump.Attributes.ProgressPercentage
Value: 100

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: 1

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: 55447806

Key  : Hypervisor.Flags.ValueHex
Value: 34e10fe

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: ffffc4000e8c8c60

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FILE_IN_CAB: MEMORY2.DMP

TAG_NOT_DEFINED_202b: *** Unknown TAG in analysis list 202b

DUMP_FILE_ATTRIBUTES: 0x21800

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXPNP: 1 (!blackboxpnp)

BLACKBOXWINLOGON: 1

PROCESS_NAME: System

STACK_TEXT:
fffffc88af4ea568 fffff80784adab01 : 000000000000001a 0000000000008840 ffffc4000e8c8c60 0000000000000000 : nt!KeBugCheckEx
fffffc88af4ea570 fffff8078480c965 : fffff807852389c0 fffff80700000000 ffffa182fa8de040 0000000000000002 : nt!MiGatherMappedPages+0x2cdfe1
fffffc88af4ea640 fffff80784887c2a : ffffa182fa8de040 ffffa182fa8de040 0000000000000080 fffff8078480c760 : nt!MiMappedPageWriter+0x205
fffffc88af4eab30 fffff80784aa0b24 : ffffd100eb790180 ffffa182fa8de040 fffff80784887bd0 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffffc88af4eab80 0000000000000000 : fffffc88af4eb000 fffffc88af4e4000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x34

SYMBOL_NAME: nt!MiGatherMappedPages+2cdfe1

MODULE_NAME: nt

STACK_COMMAND: .cxr; .ecxr ; kb

IMAGE_NAME: ntkrnlmp.exe

BUCKET_ID_FUNC_OFFSET: 2cdfe1

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

Scott_Noone_OSR · October 29, 2025, 3:49pm

Looks to me like you got a paging write on a ready only memory mapped file, which would be bad…Not sure what your filter is/does but I’d check your handling of paging reads. Verifier might help.

8: kd> dt nt!_MMPFN @$bug_param2
   +0x000 ListEntry        : _LIST_ENTRY [ 0x00000000`00000000 - 0xffffe308`b8fdbfc0 ]
   +0x000 TreeNode         : _RTL_BALANCED_NODE
   +0x000 u1               : _MIPFNFLINK
   +0x008 PteAddress       : 0xffffe308`b8fdbfc0 _MMPTE
   +0x008 PteLong          : 0xffffe308`b8fdbfc0
   +0x010 OriginalPte      : _MMPTE
   +0x018 u2               : _MIPFNBLINK
   +0x020 u3               : <unnamed-tag>
   +0x024 u5               : _MI_PFN_FLAGS5
   +0x028 u4               : _MI_PFN_FLAGS4

8: kd> !pte @$bug_param2+10 1
                                           VA ffffc4000e8c8c70
PXE at FFFFC4000E8C8C70    PPE at FFFFC4000E8C8C70    PDE at FFFFC4000E8C8C70    PTE at FFFFC4000E8C8C70
contains A18384C43E100420
contains A18384C43E100420
not valid
 Subsection: FFFFA18384C43E10
 Protect: 1 - Readonly

8: kd> dt nt!_SUBSECTION FFFFA18384C43E10
   +0x000 ControlArea      : 0xffffa183`84c43d20 _CONTROL_AREA
   +0x008 SubsectionBase   : 0xffffe308`b8fdbd68 _MMPTE
   +0x010 NextSubsection   : 0xffffa183`84c43e48 _SUBSECTION
   +0x018 GlobalPerSessionHead : _RTL_AVL_TREE
   +0x018 CreationWaitList : (null) 
   +0x020 SubsectionFlags  : _MMSUBSECTION_FLAGS
   +0x024 StartingSector   : 0xd5f
   +0x028 NumberOfFullSectors : 0x884
   +0x02c PtesInSubsection : 0x111
   +0x030 u1               : <unnamed-tag>
   +0x034 UnusedPtes       : 0y000000000000000000000000000000 (0)
   +0x034 ExtentQueryNeeded : 0y0
   +0x034 Spare            : 0y0

8: kd> !ca 0xffffa183`84c43d20

ControlArea  @ ffffa18384c43d20
  Segment      ffffe308bcccbbf0  Flink      ffffa1836fd7ea58  Blink        ffffa1836f0bc568
  Section Ref                 0  Pfn Ref                 1b8  Mapped Views                0
  User Ref                    0  WaitForDel                0  Flush Count                 0
  File Object  ffffa18386c791b0  ModWriteCount             0  System Views             ffff
  WritableRefs           300032  PartitionId                0  
  Flags (100000a0) Image File 

      \Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\Mso30win32client.dll
...

Aditya · October 30, 2025, 5:33am

Hello @Scott_Noone_OSR

Thank you very much for your analysis and for sharing the details.
We were able to identify that Mso30win32client.dll is mapped into the virtual page, which appears to have been modified by one of the kernel modules (most likely by our driver).

Since the corrupted page belongs to a DLL, can we assume that one of the kernel drivers might have corrupted the user-mode supplied buffer through the DeviceIoControl API?

Thank you for recommending the use of Driver Verifier. As the issue is observed at the customer site, we will try to obtain the VM image and execute Driver Verifier and GFlags.

Is there any other way to identify which module is causing the corruption?

Additionally, we have identified a report on Microsoft Developer Community indicating that this issue originates from Microsoft and has been acknowledged by them.
Kindly review the link below:

https://developercommunity.visualstudio.com/t/MEMORY_MANAGEMENT-BSOD-0x08840/10817202?sort=newest&type=idea

When it might be a Microsoft issue

If:

1\. The faulting address or PFN (Page Frame Number) points to a valid system structure (not random memory),

2\. The corruption originated earlier in another driver, but Windows did not catch or bug check immediately,

it might indicate a Windows memory management defect or a missing defensive validation in the kernel’s handling of corrupted memory structures.

Thank you very much

Scott_Noone_OSR · October 30, 2025, 2:49pm

Since the corrupted page belongs to a DLL, can we assume that one of the kernel drivers might have corrupted the user-mode supplied buffer through the DeviceIoControl API?

Unlikely because user pointers to images are mapped as copy on write. So, if you write to the address the data effectively gets copied out to a page file backed section (assuming there’s a paging file) so you won’t see the write back to the DLL.

Is there any other way to identify which module is causing the corruption?

Nope…The write is happening because the dirty bit was set in a PFN backing the image section. This shouldn’t happen, but if it does it usually has something to do with screwing with the MDL in the paging read path (those reads/MDLs are special because they modify the data in memory but don’t mark the PFNs dirty so it won’t get flushed out). So, at this point the damage was done possibly quite a while ago when this DLL was first paged in.

Best chance is going to be to try and repro. Or remove drivers on the system until the problem goes away in the hopes of finding a culprit, though even that’s not a guarantee that you’ll find exactly whose bug it is.

I looked the MS forum post but it was devoid of anything useful. Given that it was from December of last year you might want to see if the system has updates available, certainly can’t hurt.

Aditya · November 4, 2025, 7:43am

Hello @Scott_Noone_OSR

Thank you very much for your reply. We are trying to reproduce the issue.

Aditya · November 7, 2025, 12:17pm

Hello @Scott_Noone_OSR

When we dumped all the threads of the kernel process, we observed that both our driver and some third-party drivers are showing exceptions. It’s not yet clear whether these exceptions are a consequence of the BSOD or if they are contributing to it.

We are invoking the KeWaitForMultipleObjects API at the correct IRQL level. We also do not observe this BSOD on Windows 11 23H2 or in a Windows 11 24H2 VM environment.

We are sharing the txt file with all the threads (https://drive.google.com/file/d/1Mf-A_u42T-Zu8u1vItFQyVy9B9XQWTYw/view?usp=sharing). Request you to share your suggestions.

Thank you very much

THREAD ffffbb0f5caf1040 Cid 0004.0164 Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) KernelMode Non-Alertable
fffff8064d37d6a0 SynchronizationEvent
fffff8064d37d6b8 SynchronizationEvent
Not impersonating
DeviceMap ffffdb0f60215da0
Owning Process ffffbb0f5b692040 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 310 Ticks: 24526 (0:00:06:23.218)
Context Switch Count 1 IdealProcessor: 5
UserTime 00:00:00.000
KernelTime 00:00:00.000
Unable to load image \SystemRoot\system32\DRIVERS\NCRecognizer.sys, Win32 error 0n2
Win32 Start Address NCRecognizer!OsrWorkQueueExpander (0xfffff8064d370060)
Stack Init ffffcc853f2a0c70 Current ffffcc853f2a0770
Base ffffcc853f2a1000 Limit ffffcc853f29b000 Call 0000000000000000
Priority 8 BasePriority 8 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
ffffcc853f2a07b0 fffff806ba0566f0 : 0000000000000047 ffffbb0f5caf1040 0000000006d33ab0 0000000000000000 : nt!KiSwapContext+0x76
ffffcc853f2a08f0 fffff806ba0ce6cd : ffffbb0f5caf1040 ffff9780a1b9c180 ffffcc853f2a0ae0 fffff806ba2e7d8d : nt!KiSwapThread+0x6b0
ffffcc853f2a09c0 fffff806ba161e8a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiCommitThreadWait+0x39d
ffffcc853f2a0a50 fffff8064d3700f1 : 0000000000000000 ffffbb0f5caf1040 ffffbb0f5caf1040 d8228d336b3c5e93 : nt!KeWaitForMultipleObjects+0x48a
ffffcc853f2a0b50 fffff806ba281afa : fffff8064d37d670 fffff8064d370060 ffff9780a1b9c180 024fa46fb19bbdff : NCRecognizer!OsrWorkQueueExpander+0x91 [e:\gitlab-runner\builds\psjjyrwvw\0\portfolio\wpg\oes\winclient\drivers\ncuncfilter\src\common\osrwqueue.cpp @ 650]
ffffcc853f2a0bf0 fffff806ba49ef84 : ffff9780a1b9c180 ffffbb0f5caf1040 fffff806ba281aa0 2f2b1d663e95f93a : nt!PspSystemThreadStartup+0x5a
ffffcc853f2a0c40 0000000000000000 : ffffcc853f2a1000 ffffcc853f29b000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x34

Scott_Noone_OSR · November 7, 2025, 3:02pm

That thread is just waiting on something, no idea how/why that would cause this crash.

Is the crash happening a lot or was it just one time? I don’t imagine that there’s going to be anything in the dump to tell you how this happened. Like I said, the corruption itself might have happened quite a while ago.

Aditya · November 7, 2025, 4:10pm

Hello @Scott_Noone_OSR

Thank you for your reply. The issue is occurring on multiple PCs. The BSOD with the code 0x0000000000008840 doesn’t seem to be documented anywhere — could this be a newly introduced bug check in Windows 11, version 24H2?

When the customer uses Windows 11, version 23H2, the system works fine. It’s also unclear why Microsoft doesn’t trigger the BSOD immediately when the corruption is caused by some other component. Notably, the issue appears only on Windows 11, 24H2.

Thank you very much

Scott_Noone_OSR · November 7, 2025, 4:41pm

Sure, it could be new. Did you look? It should be easy enough to diff the output of “uf nt!MiGatherMappedPages” and see if the call to KeBugCheck appeared between 23H2 and 24H2.

My understanding after a brief look at the dump was that you’re somehow getting the dirty bit set in an image PFN. This shouldn’t happen and it would be pretty difficult to definitively detect from anywhere but the MPW I think. Also note that you’ll only see the crash if the MPW happens to wake up and try to flush out dirty pages, which it generally doesn’t do unless there’s memory pressure. You might want to try using RAMMap to periodically empty the working sets and the modified page list to see if you can flush out the bug.

Other than that the fact that it reproduces on multiple systems is good, should just be a matter of getting a hold of one of them and trying different things until you understand the problem better.

MBond2 · November 8, 2025, 12:19am

Memory corruption that occurs within a single memory space is impossible for hardware to detect at the time that it happens. A CPU instruction was executed that made a change to some address that was consistent with the page protection that existed at that time

And if the hardware can’t detect it, nothing Microsoft can do can find it either.

This is one of the reasons that older OS designs separated functions into multiple layers of trust - rings - so that single faults would not be as fatal. But there are large performance costs to that level of isolation, and the design hasn’t been used since the 80’s

That’s all part of the reason why KM programming is both hard, and heavily restricted via signing etc.

Aditya · November 8, 2025, 5:24am

Hello @Scott_Noone_OSR

Thank you for your reply. We are currently trying to reproduce the issue, but the problem is that it does not occur in a VM. Even when we use the crashed system image inside a VM, it works without any issue.

Thank you.

Aditya · November 8, 2025, 5:32am

Hello @MBond2 Thank you very much for the details.

MBond2 · November 8, 2025, 11:40pm

All except the most trivial memory corruption is hard to reproduce. And switching from a physical machine to a virtual one can have a dramatic impact on the likelihood of a crash when the problem is non-deterministic. The problem will still be present of course, but your odds of finding it via testing can go way up or way down depending on the differences in timing, paravirtualization etc.

Scott_Noone_OSR · November 9, 2025, 1:56pm

The problem involves paging so I’d recommend reducing the amount of RAM in the VM to see if that flushes the problem.

If not I’m sorry to say you’re just going to need to tinker with the system that fails. Have you asked the customer to disable other products to see if the problem still reproduces? Issues like this are a pain.

Aditya · November 9, 2025, 5:23pm

Hello @MBond2 Thank you. We are trying our best to reproduce the issue. One of the customers has agreed to raise a ticket with Microsoft. The issue only occurs under certain use cases, which makes it difficult to reproduce consistently.

Aditya · November 9, 2025, 5:34pm

Hello @Scott_Noone_OSR Thank you for your reply. Sure, we will try reducing the amount of RAM.
We are also reviewing the code, but the codebase is quite large. Thank you.

MBond2 · November 10, 2025, 1:06am

static code analysis is often one of the most effective methods for finding bugs that cause intermittent, hard to reproduce memory corruption. The biggest problem is that it is often very hard to connect the problems found this way with the crashes observed. Except that having fixed one of more issues, the rate of otherwise unexplainable crashes is reduced.

There are a bunch of tools available, but the stock ones in Visual Studio are quite good.

Another thing you can do is to annotate your code with SAL (or your own custom pattern) and const qualifiers. That’s a large commitment if you have a large code base, but it will highlight functions where the usage of parameters is unclear or inconsistent - which are all potential sources

Aditya · November 11, 2025, 4:16am

Hello @MBond2

Thank you for your response. We are currently running Git Copilot on our codebase. The drivers are based on the WDM model and are built using the legacy build.exe system.