Hello,
I need another pair of eyes to look at a crash dump as I think it doesn't make sense to me.
Here is the call stack:
Child-SP RetAddr Call Site
00 ffff9388dc87da88 fffff803
2e20d894 nt!KeBugCheckEx
01 ffff9388dc87da90 fffff803
2e08d6a9 nt!CmpCallbackFatalFilter+0x24
02 ffff9388dc87dad0 fffff803
2dbd5501 nt!CmpCallCallBacksEx$filt$0+0x19
03 ffff9388dc87db00 fffff803
2dc2361f nt!_C_specific_handler+0xa1
04 ffff9388dc87db70 fffff803
2daed243 nt!RtlpExecuteHandlerForException+0xf
05 ffff9388dc87dba0 fffff803
2dabd30e nt!RtlDispatchException+0x2f3
06 ffff9388dc87e310 fffff803
2dc2df7c nt!KiDispatchException+0x1ae
07 ffff9388dc87e9f0 fffff803
2dc29263 nt!KiExceptionDispatch+0x13c
08 ffff9388dc87ebd0 fffff803
2da6c9be nt!KiPageFault+0x463
09 ffff9388dc87ed60 fffff803
3061fbeb nt!RtlDissectName+0x5e
0a ffff9388dc87ed70 fffff803
30636cca mssecflt!RegMatchData+0x11b
0b ffff9388dc87eee0 fffff803
2dec69d5 mssecflt!SecRegCallback+0x63a
0c ffff9388dc87ef60 fffff803
2dec1445 nt!CmpCallCallBacksEx+0x225
0d ffff9388dc87f090 fffff803
2dc2d505 nt!NtQueryValueKey+0x465
0e ffff9388dc87f370 00007ffe
3ec8fc34 nt!KiSystemServiceCopyEnd+0x25
0f 00000055aaefec38 00000000
00000000 0x00007ffe`3ec8fc34
And the page fault apparenbtly happened here:
kd> u nt!RtlDissectName+0x5e
nt!RtlDissectName+0x5e:
fffff8032da6c9be 662bd1 sub dx,cx fffff803
2da6c9c1 b902000000 mov ecx,2
fffff8032da6c9c6 6603d2 add dx,dx fffff803
2da6c9c9 6683fb5c cmp bx,5Ch
fffff8032da6c9cd 66418913 mov word ptr [r11],dx fffff803
2da6c9d1 488b5c2410 mov rbx,qword ptr [rsp+10h]
fffff8032da6c9d6 4c0f44d1 cmove r10,rcx fffff803
2da6c9da 6641895302 mov word ptr [r11+2],dx
How could that happen that a "sub" instruction caused a page fault?
Thanks!
What's the full !analyze -v? Does it show a context record?
Sorry, I lost that crash dump.
I have another mysterious one that would happen quite often for a couple of weeks, and on 2 computers.
4: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
REGISTRY_FILTER_DRIVER_EXCEPTION (135)
This BugCheck is caused by an unhandled exception in a registry filtering driver.
This BugCheck indicates that a registry filtering driver didn't handle exception inside
its notification routine. One can identify the driver by the 3rd parameter.
Arguments:
Arg1: ffffffffc0000005, ExceptionCode
Arg2: ffffa500470f5f80, Address of the context record for the exception that caused the BugCheck
Arg3: fffff8011758e4e0, The driver's callback routine address
Arg4: ffff938c18350f80, Internal
Debugging Details:
------------------
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 2078
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 2423
Key : Analysis.Init.CPU.mSec
Value: 10390
Key : Analysis.Init.Elapsed.mSec
Value: 511274471
Key : Analysis.Memory.CommitPeak.Mb
Value: 195
Key : WER.OS.Branch
Value: ni_release_svc_prod3
Key : WER.OS.Timestamp
Value: 2023-10-18T18:09:00Z
Key : WER.OS.Version
Value: 10.0.22621.2506
FILE_IN_CAB: MEMORY.DMP
DUMP_FILE_ATTRIBUTES: 0x1000
BUGCHECK_CODE: 135
BUGCHECK_P1: ffffffffc0000005
BUGCHECK_P2: ffffa500470f5f80
BUGCHECK_P3: fffff8011758e4e0
BUGCHECK_P4: ffff938c18350f80
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
PROCESS_NAME: DellSupportAssistRemedationService.exe
STACK_TEXT:
ffffa500`470f56c8 fffff801`19c0cff4 : 00000000`00000135 ffffffff`c0000005 ffffa500`470f5f80 fffff801`1758e4e0 : nt!KeBugCheckEx
ffffa500`470f56d0 fffff801`19a917b9 : ffffa500`470f69a0 fffff801`198d17d0 ffffa500`470f5d40 fffff801`198cab35 : nt!CmpCallbackFatalFilter+0x24
ffffa500`470f5710 fffff801`195d6901 : ffffa500`00000003 ffffa500`470f6768 ffffa500`470f1000 ffffa500`470f8000 : nt!CmpCallCallBacksEx$filt$0+0x19
ffffa500`470f5740 fffff801`196258df : ffffa500`470f6768 ffffa500`470f5d40 ffffa500`470f6700 fffff801`198cab35 : nt!_C_specific_handler+0xa1
ffffa500`470f57b0 fffff801`194a0013 : ffffa500`470f6ae0 ffffa500`470f6768 fffff801`198cab35 fffff801`1930dcf0 : nt!RtlpExecuteHandlerForException+0xf
ffffa500`470f57e0 fffff801`19405ebe : ffffffff`ffffffff ffffa500`470f6810 ffffa500`470f6810 ffffa500`470f5f80 : nt!RtlDispatchException+0x2f3
ffffa500`470f5f50 fffff801`1963027c : 00000000`00001000 ffffa60f`3c972800 00000000`00000000 ffffa500`470f6730 : nt!KiDispatchException+0x1ae
ffffa500`470f6630 fffff801`1962b563 : 00000000`00000000 ffffa500`470f6940 00000000`00000000 ffff938b`ffd4b240 : nt!KiExceptionDispatch+0x13c
ffffa500`470f6810 fffff801`198d17d0 : ffff938c`149a3630 ffffa500`470f6a79 00000000`00000030 fffff801`1994ba66 : nt!KiPageFault+0x463
ffffa500`470f69a0 fffff801`1758c9d1 : ffffa500`470f70a0 00000000`00000000 ffffa60f`51c8fab0 ffffa500`470f6d80 : nt!RtlCompareUnicodeString+0x70
ffffa500`470f69e0 fffff801`1758e447 : 00000000`00000000 ffffa500`470f6aa0 ffffa60f`51c85de0 00000000`00000000 : MyDriver!CanCheckKey+0xb1
ffffa500`470f6a20 fffff801`1758e60b : ffff938c`149a3600 ffffa500`470f6cf0 ffffa500`470f6c00 fffff801`19920100 : MyDriver!OnOpenKeyPreProc+0x28b
ffffa500`470f6ae0 fffff801`198cab35 : ffffa500`470f6cf0 ffff938c`11a7d910 ffff938c`18350f80 ffff938c`18350f80 : MyDriver!OnRegCallback+0x12b
ffffa500`470f6b60 fffff801`198c8f0f : 00000000`0000001c ffffa500`470f6d80 ffffa500`470f6d08 00000000`00000001 : nt!CmpCallCallBacksEx+0x225
ffffa500`470f6c90 fffff801`198d0b44 : fffff801`198c8c00 ffffa60f`00000000 ffffa60f`46cd56a0 ffffa500`470f6f01 : nt!CmpParseKey+0x26f
ffffa500`470f6e80 fffff801`198cf4f2 : ffffa60f`46cd5601 ffffa500`470f70a0 00000000`00000040 ffffa60f`177c3640 : nt!ObpLookupObjectName+0x1104
ffffa500`470f7010 fffff801`198a9854 : 00000000`00000000 ffffa60f`177c3640 00000000`00000000 00000000`00000000 : nt!ObOpenObjectByNameEx+0x1f2
ffffa500`470f7140 fffff801`199b3758 : 00000014`859fc5f8 00000000`00000000 00000000`00000000 fffff801`199640ec : nt!CmOpenKey+0x2c4
ffffa500`470f7390 fffff801`1962f805 : ffffa60f`52825080 ffffa60f`57fd38e0 00000000`00240040 00000208`ebee0340 : nt!NtOpenKeyEx+0x48
ffffa500`470f73e0 00007ffb`accb24b4 : 00007ffb`aa2a0334 00000014`859fc938 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25
00000014`859fc5d8 00007ffb`aa2a0334 : 00000014`859fc938 00000000`00000000 00000000`00000000 00000000`00000004 : ntdll!NtOpenKeyEx+0x14
00000014`859fc5e0 00007ffb`aa29f518 : 00000000`000003c0 00000014`859fca38 00000000`00000000 00000014`859fd080 : KERNELBASE!LocalBaseRegOpenKey+0x1d4
00000014`859fc8f0 00007ffb`aa29f3c9 : 00000000`000003c0 00000014`859fca28 00000000`00000000 00000000`00000004 : KERNELBASE!RegOpenKeyExInternalW+0x138
00000014`859fc980 00007ffb`3bcbe1ee : 00000014`859fca28 00000014`859fca28 00007ffb`3be76620 00000014`859fcc60 : KERNELBASE!RegOpenKeyExW+0x19
00000014`859fc9c0 00000014`859fca28 : 00000014`859fca28 00007ffb`3be76620 00000014`859fcc60 00000014`859fca38 : InstantRestore!GetLatestSnapshotAppliedDateTime+0x31dbe
00000014`859fc9c8 00000014`859fca28 : 00007ffb`3be76620 00000014`859fcc60 00000014`859fca38 00000000`00000000 : 0x00000014`859fca28
00000014`859fc9d0 00007ffb`3be76620 : 00000014`859fcc60 00000014`859fca38 00000000`00000000 00000000`00000000 : 0x00000014`859fca28
00000014`859fc9d8 00000014`859fcc60 : 00000014`859fca38 00000000`00000000 00000000`00000000 4c9654d6`25292dc4 : InstantRestore!GetLatestSnapshotAppliedDateTime+0x1ea1f0
00000014`859fc9e0 00000014`859fca38 : 00000000`00000000 00000000`00000000 4c9654d6`25292dc4 00000014`859fca28 : 0x00000014`859fcc60
00000014`859fc9e8 00000000`00000000 : 00000000`00000000 4c9654d6`25292dc4 00000014`859fca28 00000014`859fca30 : 0x00000014`859fca38
SYMBOL_NAME: nt!CmpCallbackFatalFilter+24
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 24
FAILURE_BUCKET_ID: 0x135_nt!CmpCallbackFatalFilter
OS_VERSION: 10.0.22621.2506
BUILDLAB_STR: ni_release_svc_prod3
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {268799ab-cadc-ad38-fc81-f5ce11e413d5}
Followup: MachineOwner
---------
I went to frame 8:
.frame /c 8
08 ffffa500`470f6810 fffff801`198d17d0 nt!KiPageFault+0x463
rax=ffffa500470f6768 rbx=ffffa60f576e9a76 rcx=0000000000000135
rdx=ffffffffc0000005 rsi=fffff80130ce0004 rdi=0000000000000033
rip=fffff8011962b563 rsp=ffffa500470f6810 rbp=ffffa500470f6890
r8=ffffa500470f5f80 r9=fffff8011758e4e0 r10=0000000000000018
r11=ffffa500470f57b0 r12=0000000000000000 r13=0000000000000000
r14=000000000000ffe0 r15=00000000000000c0
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040282
nt!KiPageFault+0x463:
fffff801`1962b563 440f20c0 mov rax,cr8
kd> u nt!KiPageFault
nt!KiPageFault:
fffff801`1962b100 55 push rbp
fffff801`1962b101 4881ec58010000 sub rsp,158h
fffff801`1962b108 488dac2480000000 lea rbp,[rsp+80h]
fffff801`1962b110 c645ab01 mov byte ptr [rbp-55h],1
fffff801`1962b114 488945b0 mov qword ptr [rbp-50h],rax
fffff801`1962b118 48894db8 mov qword ptr [rbp-48h],rcx
fffff801`1962b11c 488955c0 mov qword ptr [rbp-40h],rdx
fffff801`1962b120 4c8945c8 mov qword ptr [rbp-38h],r8
and then calculated the previous RSP (at the time of the page fault) = ffffa500470f6970
> dq ffffa500470f6970
ffffa500`470f6970 00000000`00000002 fffff801`198d17d0
ffffa500`470f6980 00000000`00000010 00000000`00050287
ffffa500`470f6990 ffffa500`470f69a0 00000000`00000018
ffffa500`470f69a0 ffff938c`149a3630 ffffa500`470f6a79
ffffa500`470f69b0 00000000`00000030 fffff801`1994ba66
ffffa500`470f69c0 fffff801`17596578 ffffa500`470f7200
ffffa500`470f69d0 ffffa60f`576e99e0 fffff801`1758c9d1
So it seems the page fault error code is 2 which means
the page was not present and the access causing the fault was a write.
The RIP = fffff801`198d17d0
is indeed at
d> u fffff801`198d17d0
nt!RtlCompareUnicodeString+0x70:
fffff801`198d17d0 410fb711 movzx edx,word ptr [r9]
One strange thing is that CR2 is
kd> ?cr2
Evaluate expression: 51 = 00000000`00000033
wc2023
July 19, 2024, 2:58pm
5
Yes, your exception happens in nt!RtlCompareUnicodeString
- see what address you are reading from. It is in r9
. Add it to the !pte <addr>
command to see what is happening with that page in memory. My guess is that it was either paged out, or you're reading from some bad address (from a bad pointer.)
Good question.
I've been looking at the memory for quite some time, and the strange thing is that it is valid.
If you take a look at the function RtlCompareUnicodeString, it obviously iterates over the strings comparing each character, and the exception happens somewhere in the middle of the string.
R9 contains ffff938f733f5e4e
> .frame /c 9
09 ffffbb8d`dcdf69a0 fffff800`54a4c9d1 nt!RtlCompareUnicodeString+0x70
rax=0000000000000033 rbx=ffff938f733f5e86 rcx=0000000000000000
rdx=0000000000000045 rsi=fffff80059840004 rdi=0000000000000033
rip=fffff8003f0d17d0 rsp=ffffbb8ddcdf69a0 rbp=0000000000000033
r8=0000000000000001 r9=ffff938f733f5e4e r10=0000000000000045
r11=ffffed7fa28203f0 r12=0000000000000000 r13=0000000000000000
r14=000000000000ffe0 r15=00000000000000c0
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040282
nt!RtlCompareUnicodeString+0x70:
fffff800`3f0d17d0 410fb711 movzx edx,word ptr [r9] ds:002b:ffff938f`733f5e4e=004d
4: kd> dc ffff938f733f5e4e
ffff938f`733f5e4e 005c004d 00750043 00720072 006e0065 M.\.C.u.r.r.e.n.
The string buffer starts at ffff938f733f5e20
> dc ffff938f733f5e20
ffff938f`733f5e20 0052005c 00470045 00530049 00520054 \.R.E.G.I.S.T.R.
ffff938f`733f5e30 005c0059 0041004d 00480043 004e0049 Y.\.M.A.C.H.I.N.
ffff938f`733f5e40 005c0045 00590053 00540053 004d0045 E.\.S.Y.S.T.E.M.
ffff938f`733f5e50 0043005c 00720075 00650072 0074006e \.C.u.r.r.e.n.t.
ffff938f`733f5e60 006f0043 0074006e 006f0072 0053006c C.o.n.t.r.o.l.S.
ffff938f`733f5e70 00740065 0053005c 00720065 00690076 e.t.\.S.e.r.v.i.
ffff938f`733f5e80 00650063 00000073 00000000 00000000 c.e.s...........
Given that, it should be ovious that the string is not paged out.
!pte command unfortunately fails with "Levels not implemented for this platform", but nevertheless I translated the linear address to a physical address by hand, and all the higher level directory pages are valid, as well as the physical frame for the linear address. I can post my translation here if you're interested.
You're at IRQL PASSIVE_LEVEL when you call RtlCompareUnicodeString?
Yes, the IRQL is PASSIVE_LEVEL.