Code:
BugCheck 1A, {41287, 0, 0, 0}
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+10837 )
The bugcheck indicates that a illegal page fault occurred during working set synchronization. If we dump the process, then is a 10's of User-Mode threads all waiting on synchronization timers and synchronization events.
Code:
0: kd> knL
# Child-SP RetAddr Call Site
00 ffffd000`27dda498 fffff802`5f5789e7 nt!KeBugCheckEx
01 ffffd000`27dda4a0 fffff802`5f561f2f nt! ?? ::FNODOBFM::`string'+0x10837
02 ffffd000`27dda5e0 fffff802`5f45c062 nt!KiPageFault+0x12f
03 ffffd000`27dda770 fffff802`5f7e45bc nt!MiCommitExistingVad+0x5b2
04 ffffd000`27dda890 fffff802`5f5634b3 nt!NtAllocateVirtualMemory+0x46c
05 ffffd000`27ddaa90 00007ffb`fe3017fa nt!KiSystemServiceCopyEnd+0x13
06 00000000`0e48c2a8 00007ffb`fe2a239d ntdll!NtAllocateVirtualMemory+0xa
07 00000000`0e48c2b0 00007ffb`fe2a1347 ntdll!RtlpFindAndCommitPages+0x3bd
08 00000000`0e48c310 00007ffb`fe29f625 ntdll!RtlpExtendHeap+0x37
09 00000000`0e48c420 00007ffb`fe29ddb4 ntdll!RtlpAllocateHeap+0x8c5
0a 00000000`0e48c710 00007ffb`fe2a9ca5 ntdll!RtlAllocateHeap+0x184
0b 00000000`0e48c820 00007ffb`fe29e910 ntdll!RtlpAllocateUserBlockFromHeap+0x5d
0c 00000000`0e48c8a0 00007ffb`fe29dd0e ntdll!RtlpLowFragHeapAllocFromContext+0xac0
0d 00000000`0e48c960 00007ffb`ecd092c3 ntdll!RtlAllocateHeap+0xde
From the call stack, it seems that that the page fault happened due to a memory allocation. More specially, a user-mode program has requested a memory allocation, thus leading to the
NtAllocateVirtualMemory function being called from the SSDT.
Code:
0: kd> !dpx
Start memory scan : 0xffffd00027dda498 ($csp)
End memory scan : 0xffffd00027ddb000 (Stack Base)
0xffffd00027dda540 : 0xffffd00027dda748 : 0xfffff8025f45c062 : nt!MiCommitExistingVad+0x5b2
0xffffd00027dda588 : 0xfffff8025f49593b : nt!MiMigratePfn+0x6b
0xffffd00027dda5d8 : 0xfffff8025f561f2f : nt!KiPageFault+0x12f
0xffffd00027dda5e0 : 0x0000000000000001 : Trap @ ffffd00027dda5e0
0xffffd00027dda5f0 : 0xffffe0012a9e4800 : !da "RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR"
0xffffd00027dda648 : 0xfffff8025f49e121 : nt!MiReplenishPageSlist+0x231
0xffffd00027dda6c8 : 0xfffff8025f49d796 : nt!MiRemoveAnyPage+0x1f6
0xffffd00027dda6d0 : 0xfffff8025f7506c0 : nt!MmZeroedPageListHead
0xffffd00027dda6f8 : 0xfffff8025f7e58de : nt!MiCommitPageTablesForVad+0x1fa
0xffffd00027dda748 : 0xfffff8025f45c062 : nt!MiCommitExistingVad+0x5b2
0xffffd00027dda888 : 0xfffff8025f7e45bc : nt!NtAllocateVirtualMemory+0x46c
0xffffd00027dda9b8 : 0xfffff8025f4544eb : nt!MmAccessFault+0x42b
0xffffd00027ddaa88 : 0xfffff8025f5634b3 : nt!KiSystemServiceCopyEnd+0x13
0xffffd00027ddaad0 : 0x000000000e76e380 : dt Windows_UI_Xaml!XamlBinaryFormatReader
0xffffd00027ddaaf8 : 0xfffff8025f562057 : nt!KiPageFault+0x257
0xffffd00027ddab00 : 0x0000000000000001 : Trap @ ffffd00027ddab00
0xffffd00027ddab58 : 0x00007ffbfe2738b0 : ntdll!RtlpBitsClearLow
0xffffd00027ddac68 : 0x00007ffbfe3017fa : ntdll!NtAllocateVirtualMemory+0xa
0xffffd00027ddac80 : 0x000000000e48c2a8 : 0x00007ffbfe2a239d : ntdll!RtlpFindAndCommitPages+0x3bd
I'm assuming we're allocating from a zeroed page due to the reference of the
nt!MmZeroedPageListHead, which is the variable that stores the address of the list head for the zeroed page doubly linked list.
Code:
0: kd> !memusage 8
loading PFN database
loading (100% complete)
Compiling memory usage data (99% Complete).
Zeroed: 3227 ( 12908 kb)
Free: 1616293 (6465172 kb)
Standby: 98050 (392200 kb)
Modified: 11539 ( 46156 kb)
ModifiedNoWrite: 0 ( 0 kb)
Active/Valid: 345310 (1381240 kb)
Transition: 1716 ( 6864 kb)
Bad: 233 ( 932 kb)
Unknown: 0 ( 0 kb)
TOTAL: 2076135 (8304540 kb)
The above extension is parsed from the following structure called _MMLISTS:
Code:
0: kd> dt nt!_MMLISTS
ZeroedPageList = 0n0
FreePageList = 0n1
StandbyPageList = 0n2
ModifiedPageList = 0n3
ModifiedNoWritePageList = 0n4
BadPageList = 0n5
ActiveAndValid = 0n6
TransitionPage = 0n7
Code:
0: kd> .trap 0xffffd00027dda5e0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000fffffffff
rdx=fffff6fb7da00000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8025f45c062 rsp=ffffd00027dda770 rbp=000000000ea93000
r8=fffff6fb400003a8 r9=00000000ffffffff r10=0000000000000011
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt!MiCommitExistingVad+0x5b2:
fffff802`5f45c062 897c2438 mov dword ptr [rsp+38h],edi ss:0018:ffffd000`27dda7a8=21000000
0: kd> r.
Last set context:
rsp=ffffd000`27dda770 edi=00000000`00000000
The second parameter of the bugcheck contains the referenced address, which seems to be invalid, and is most likely the cause of the bugcheck. The IRQL Level is 0, and so the IRQL Level isn't a problem.
Code:
0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 0 (LOW_LEVEL)
I would suggest running Driver Verifier for 24 hours, and then posting any BSODs which are produced.
https://www.sysnative.com/forums/bs...ted-windows-10-8-1-8-7-and-windows-vista.html
More Information -
Using Driver Verifier to identify issues with Windows drivers for advanced users
Please also configure your dump file settings to a
Kernel Memory Dump:
- Computer
- System Properties
- Advanced System Settings
- Under Startup and Recovery, select Settings
- Under Write Debugging Information, change to Kernel Memory Dump
View attachment 10022
