关于TCI的Z:\pagefile无助于蓝屏dmp生成的研究的阶段性研究
1 背景知识
1.1 TCI的磁盘分区和启动
真实磁盘做了若干分区，其中一个分区姑且称为lessons分区，一个分区姑且称为rainmisc分区。
root@RainOS:~# fdisk -l
Device Start End Sectors Size Type
/dev/sda1 2048 206847 204800 100M EFI System
/dev/sda2 206848 411647 204800 100M Microsoft reserved
/dev/sda3 411648 5294079 4882432 2.3G Microsoft reserved
/dev/sda4 5294080 14626079 9332000 4.5G Linux filesystem
/dev/sda5 14626816 500117503 485490688 231.5G Linux filesystem
root@RainOS:~# blkid
/dev/sda4: LABEL="RJSYSTEM" UUID="6a379460-dea1-4375-951f-20aba88be370" TYPE="ext4" PARTLABEL="RainOS" PARTUUID="09e056b8-546b-4cd0-b2c7-4e30f7af4c76"
/dev/sda5: LABEL="RJLESSON" UUID="aab520a0-14cf-4301-bfbc-213f9d136f8d" TYPE="ext4" PARTLABEL="lessons" PARTUUID="ffe0885c-aac6-4a69-b331-b1ee5e6d4354"
/dev/loop7: UUID="b97abebe-9d7b-4a58-aea7-b5d5b7dabd5b" TYPE="ext4"
/dev/sda1: SEC_TYPE="msdos" LABEL_FATBOOT="RJBOOT" LABEL="RJBOOT" UUID="5BB4-0B99" TYPE="vfat" PARTLABEL="RainBoot" PARTUUID="b8d004ae-1b78-43ee-b206-f42d9106f4ae"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="RJMISC" LABEL="RJMISC" UUID="5BB4-7C94" TYPE="vfat" PARTLABEL="RainMisc" PARTUUID="e4e2f80d-f86a-4f46-abd9-37f71e642da4"
/dev/sda3: LABEL_FATBOOT="RJRECOVE" LABEL="RJRECOVE" UUID="5BB5-08D3" TYPE="vfat" PARTLABEL="RainRecovery" PARTUUID="cfb4742e-6d97-4c90-954e-043386ceb672"
lessons rainmisc
文件系统 ext4 vfat
分区大小 大约整个磁盘空间的90% 100MB
rainos(Linux）下的挂载目录 /opt/lessons 无所谓
Windows下的挂载盘符 Z: Y:
存放文件 SYSTEM.qcow2，data.disk等 pagefile.sys
终端的电源开机按钮按下后，主板上的EFI程序（可以理解为一种操作系统）会去解析lessons分区里的SYSTEM.qcow2，找出并执行里面的winload.efi。winload.efi会找出并执行SYSTEM.qcow2里的ntoskrnl.exe，由此操作系统由efi切换到windows。
30G的qcow2文件如何模拟成一个200G的磁盘，诸如如何定位并读取磁盘的0~512B这段数据？是通过vdisk.sys实现的。
qcow2文件又是lessons分区ext文件系统的分区里的一个文件，Windows系统要想知道SYSTEM.qcow2文件的在lessons分区里的起始地址，如何从ext分区里读写文件，就需要ext2fsd.sys。
ntoskrnl启动的早期阶段就加载了ext2fsd.sys，所以Windows能够理解ext文件系统，能够从lessons分区里找到并读写qcow2文件。
ntoskrnl启动的早期阶段就加载了vdisk.sys，所以Windows能够将SYSTEM.qcow2和data.disk当作真实磁盘一样使用。
1.2 Windows蓝屏dmp的通常流程和设置
A. 注册表中配置pagefile.sys文件的位置和大小，一般是C:\pagefile.sys，大小一般是自动
B. Windows启动的早期阶段会把存储栈做一个备份（如dump_iaStorAC.sys、dump_diskdump.sys、dump_dumpfve.sys等），使得即使是蓝屏时刻，即使原先的iaStorAC.sys都出了问题，Windows也有能力把内存数据写到磁盘的某段空间去。
C. 蓝屏时，执行crashdmp!CrashdmpInitDumpStack，改用这个备用的存储栈，把内存数据写到pagefile.sys文件里
D. 蓝屏后重启或关机再开机，若检测到pagefile.sys的前六个字母时PAGEDU，则把pagefile.sys数据复制到dmp文件里，进而形成dmp文件。
1.3 TCI蓝屏dmp的方案和缺陷
1.3.1 TCI原先的蓝屏dmp方案
A. 注册表中配置pagefile.sys文件的位置是Y:\pagefile.sys，大小是64MB。
B. 蓝屏dmp只能配置成minidump，而不是kerneldump
C. Z:\pagefile.sys虽然文件大小可以充分大，但不能用于蓝屏dmp的生成，只能用于日常运行的虚拟内存
1.3.2 缺陷
A. 因为rainmisc空间（Y盘）有限，Y:\pagefile.sys文件大小也有限，所以dmp文件大小只能是minidump
B. Z:\pagefile.sys虽然文件大小可以充分大，但不能用于蓝屏dmp的生成。能触发蓝屏，但是蓝屏dmp生成画面的进度在0%之后就结束了。
2 分析和解决思路
2.1 分析
已知TCI的Y盘（vfat文件系统分区）Z盘（ext文件系统分区）都是同一个存储设备上的两个不同分区，而Y:\pagefile有助于蓝屏dmp生成，因此我认为Z:\pagefile无助于蓝屏生成并不是因为存储栈不完备，而是因为它的文件系统，或者说ext文件系统驱动缺少相关功能。
2.2 思考定位方法
已知Z:\pagefile.sys无助于蓝屏生成是必现的。已知蓝屏dmp生成步骤分为蓝屏时数据写入pagefile和重启后pagefile数据导入dmp文件两个步骤。而且这两个步骤也是可以调试的。那么我们可以用普通虚机和TCI一起触发蓝屏，进行调试，查看TCI环境里哪个步骤哪个函数哪个ifelse分支跟普通虚机不同，进而挖出根因所在。
3 测试环境
使用windows iso\cn_windows_10_business_editions_version_1909_updated_jan_2020_x64_dvd_b3e1f3a6.iso安装win10专业版，nt版本10.0.18362.592，crashdmp.sys版本10.0.18362.1。一个环境是TCI，pagefile仅仅设在Z盘（ext文件系统分区），一个环境是普通qemu虚机（用物理机或virtualbox虚机也行），pagefile仅仅设在C盘（ntfs文件系统分区）。
qemu虚机的命令行是：
qemu-system-x86_64 -enable-kvm -m 4G
-device piix3-usb-uhci -device usb-tablet
-vnc 0.0.0.0:0
-drive file=/usr/share/qemu-kvm/OvmfX64/OVMF.fd,format=raw,if=pflash,unit=0,readonly=on
-device ahci
-device ide-hd,drive=disk
-drive id=disk,if=none,file=./win10x64.1909.qcow2
-monitor stdio
3.1 设置通过网卡来调试Windows内核
虚机执行如下配置。
hostip就是你运行windbg的机器，要求虚机能够ping到此机。noumex表示用户态的异常不会触发调试暂停。busparam 0.3.0表示虚机的网卡的位置。
重启虚机后，windbg执行内核调试，可调试此虚机。看到如下文字表示调试的连接成功了：
Waiting to reconnect...
Connected to target 10.52.64.43 on port 56443 on local IP 10.52.64.41.
You can get the target MAC address by running .kdtargetmac command.
Connected to Windows 10 18362 x64 target at (Fri Jul 7 16:25:48.531 2023 (UTC + 8:00)), ptr64 TRUE
Kernel Debugger connection established. (Initial Breakpoint requested)
** Path validation summary ***
Response Time (ms) Location
Deferred srvD:\pdb https://msdl.microsoft.com/download/symbols
Symbol search path is: srvD:\pdb https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 10 Kernel Version 18362 MP (1 procs) Free x64
Edition build lab: 18362.1.amd64fre.19h1_release.190318-1202
Machine Name:
Kernel base = 0xfffff8017b800000 PsLoadedModuleList = 0xfffff8017bc48150
3.2 蓝屏设置
使用notmyfault来触发蓝屏。
设置dmp为核心转储。
对于普通qemu虚机，虚机里我的电脑属性中pagefile设置到C盘。对于TCI，则设置到Z盘。
4 实验记录
4.1 第一层分歧------蓝屏时不能走到CrashdmpInitDumpStack
qemu环境开机后，先触发蓝屏，下断点bp crashdmp!CrashdmpInitDumpStack
继续执行被调试机，调试器就会捕捉到如下栈：
Child-SP RetAddr Call Site
00 ffffa207cbdbede8 fffff801745c48a7 crashdmp!CrashdmpInitDumpStack
01 ffffa207cbdbedf0 fffff801710ad52e crashdmp!CrashdmpWrite+0x167
02 ffffa207cbdbee20 fffff801710bff2e nt!IoWriteCrashDump+0x542
03 ffffa207cbdbef80 fffff80170fd85e7 nt!KeBugCheck2+0xc6e
04 ffffa207cbdbf680 fffff80170fea2e9 nt!KeBugCheckEx+0x107
05 ffffa207cbdbf6c0 fffff80170fe662b nt!KiBugCheckDispatch+0x69
06 ffffa207cbdbf800 fffff80175b41981 nt!KiPageFault+0x46b
07 ffffa207cbdbf990 fffff80175b41d3d myfault+0x1981
分析一下栈回溯：
kd> ub crashdmp!CrashdmpWrite+0x167
crashdmp!CrashdmpWrite+0x141:
fffff80d6d264881 e89a6f0000 call crashdmp!CrashdmpTelemetrySaveEnvironmentVariable (fffff80d6d26b820)
fffff80d6d264886 e9ad000000 jmp crashdmp!CrashdmpWrite+0x1f8 (fffff80d6d264938)
fffff80d6d26488b 8b057fb20000 mov eax,dword ptr [crashdmp!Context+0x70 (fffff80d6d26fb10)]
fffff80d6d264891 a840 test al,40h
fffff80d6d264893 0f8583000000 jne crashdmp!CrashdmpWrite+0x1dc (fffff80d6d26491c)
fffff80d6d264899 488b0d50b20000 mov rcx,qword ptr [crashdmp!Context+0x50 (fffff80d6d26faf0)]
fffff80d6d2648a0 33d2 xor edx,edx
fffff80d6d2648a2 e859f4ffff call crashdmp!CrashdmpInitDumpStack (fffff80d6d263d00)
kd> ub nt!IoWriteCrashDump+0x542
nt!IoWriteCrashDump+0x520:
fffff8016c29650c 49894628 mov qword ptr [r14+28h],rax
fffff8016c296510 4c8b75a8 mov r14,qword ptr [rbp-58h]
fffff8016c296514 85ff test edi,edi
fffff8016c296516 7818 js nt!IoWriteCrashDump+0x544 (fffff8016c296530)
fffff8016c296518 488b05893d1d00 mov rax,qword ptr [nt!CrashdmpCallTable+0x38 (fffff8016c46a2a8)]
fffff8016c29651f 498bd5 mov rdx,r13
fffff8016c296522 488b0d3f3d1d00 mov rcx,qword ptr [nt!CrashdmpDumpBlock (fffff8016c46a268)]
fffff8016c296529 e8c23af3ff call nt!guard_dispatch_icall (fffff8016c1c9ff0)
kd> u poi(nt!CrashdmpCallTable+0x38)
crashdmp!CrashdmpWrite:
fffff80d`6d264740 4889742408 mov qword ptr [rsp+8],rsi
意思是在nt!IoWriteCrashDump+53D处代码是call nt!guard_dispatch_icall，即调用crashdmp!CrashdmpWrite，crashdmp!CrashdmpWrite+162处又调用crashdmp!CrashdmpInitDumpStack。
在TCI里，即使设置了断点bp crashdmp!CrashdmpInitDumpStack，也不会触发，那么我们就在上层调用函数处设置断点，看看哪个函数没有执行到：
bp crashdmp!CrashdmpWrite+162
bp nt!IoWriteCrashDump+53D
bp nt!IoWriteCrashDump
而TCI的蓝屏，只能走到这：
Child-SP RetAddr Call Site
00 ffffc3839bd0eb38 fffff800104a8f2e nt!IoWriteCrashDump
01 ffffc3839bd0eb40 fffff800103c15e7 nt!KeBugCheck2+0xc6e
02 ffffc3839bd0f240 fffff800103d32e9 nt!KeBugCheckEx+0x107
03 ffffc3839bd0f280 fffff800103cf62b nt!KiBugCheckDispatch+0x69
04 ffffc3839bd0f3c0 fffff8002d1f1981 nt!KiPageFault+0x46b
05 ffffc3839bd0f550 fffff8002d1f1d3d myfault+0x1981
使用ida分析ntoskrnl.exe，Load对应pdb，转入IoWriteCrashDump函数。
先关注第一个ifelse分支IoWriteCrashDump+82处，看看此处qemu和tci的跳转是否一致。
发现此处nt!IoWriteCrashDump函数内会检测
db nt!CapsuleTriageDumpBlockInitialized L1是否是0。若0则正常。若非0则不会走到crashdmp!CrashdmpWrite，进而就没法生成蓝屏dmp。
4.2 第二层分歧------开机时赋值CapsuleTriageDumpBlockInitialized
使用windbg硬件断点监控数据nt!CapsuleTriageDumpBlockInitialized的写入时机。在一开机时就设置写断点：
ba w1 nt!CapsuleTriageDumpBlockInitialized"db nt!CapsuleTriageDumpBlockInitialized L1;!thread"。
qemu环境里，一开始CapsuleTriageDumpBlockInitialized是0。写断点第一次触发时，它变为1，是在System进程的nt!IopInitDumpCapsuleSupport+4e里做的。写断点第二次触发时，它变为0，是在System进程的nt!IopRemoveDumpCapsuleSupport+0x36里做的。
对应TCI环境里CapsuleTriageDumpBlockInitialized赋值为1，是在刚开机时候smss进程做的，栈如下：
Child-SP RetAddr : Args to Child : Call Site
ffff9d8add4427c0 fffff8057a01c25c : ffffa403f65c9080 ffffffff800005b8 ffff9d8a00000003 ffff9d8add442960 : nt!IopInitDumpCapsuleSupport+0x4e
ffff9d8add4427f0 fffff80579f6dd62 : ffffa403f81f7050 fffff80579c6a400 ffffa403f81f7050 fffff80579c6a400 : nt!IoInitializeCrashDump+0xadb8c
ffff9d8add442830 fffff80579f6d65d : ffffa403f65c9080 0000000000000001 0000000000000000 0000000000000001 : nt!MiCreatePagingFile+0x6fa
ffff9d8add4429c0 fffff805799d2d15 : ffffa403f65c9080 ffffa403f65c7d50 ffff9d8add442a80 ffffa403f64d4d60 : nt!NtCreatePagingFile+0x2d
ffff9d8add442a00 00007fff5669d6d4 : 00007ff64c1ba231 00006c141744f7fc 0000000000000000 0000024ef10081b0 : nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff9d8add442a00) 000000e1256ff2f8 00007ff64c1ba231 : 00006c141744f7fc 0000000000000000 0000024ef10081b0 0000024ef1008290 : ntdll!NtCreatePagingFile+0x14 000000e1256ff300 00007ff64c1ba4ec : 0000000600000000 0000000020000000 0000024ef10081a0 0000000000000001 : smss!SmpCreatePagingFile+0x25 000000e1256ff330 00007ff64c1bab93 : fffffff79e3b9800 0000000000000084 0000000000000001 0000000020000000 : smss!SmpCreatePagefileOnVolume+0x158 000000e1256ff3f0 00007ff64c1bac2e : 0000024ef10081a0 000000e1256ff748 0000024ef10081a0 00007ff64c1c72e0 : smss!SmpCreatePagefileFromDescriptor+0x6b 000000e1256ff420 00007ff64c1badca : 0000000020000000 0000000600000000 0000024ef10051a0 00007ff64c1d2320 : smss!SmpProcessPagefileDescriptor+0x6e 000000e1256ff450 00007ff64c1bb7df : 0000000000000002 0000024ef1005401 0000024ef1005401 0000024ef10054d8 : smss!SmpCreatePagingFiles+0x18a 000000e1256ff4a0 00007fff5663089d : 0000024ef1005410 000000007ffe0386 000000e1256ff748 0000024ef10054d8 : smss!SmpAsyncMemoryConfiguration+0x9f 000000e1256ff4e0 00007fff56634634 : 0000000000000000 0000024ef1004890 0000000000000000 0000000000000000 : ntdll!TppWorkpExecuteCallback+0xad 000000e1256ff530 00007fff5666cedf : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!TppWorkerThread+0x8d4 000000e1256ff8f0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x2f
这是session=none的smss进程。
4.3 第三层分歧------smss调用IoInitializeCrashDump和IopInitDumpCapsuleSupport
对比刚开机时候的smss进程，qemu环境也执行了IoInitializeCrashDump但没执行IopInitDumpCapsuleSupport。查看IoInitializeCrashDump函数内容里面给各个分支下断点，QEMU和TCI虚机都进行比较看看。
这里先选取前两个分支点：
bp nt!IoInitializeCrashDump+1C;bp nt!IoinitializeCrashDump+57
注意当前进程!process是否是smss
这是因为qemu环境里IoInitializeCrashDump里面调用函数IopInitializeCrashDump的返回值是1。
4.4 第四层分歧------IopInitializeCrashDump和CrashdmpInitialize
而返回值是1的关键在于nt!IopInitializeCrashDump+ad处的call _guard_dispatch_icall qemu环境里返回0，而TCI返回c000000f。
易知这里的call _guard_dispatch_icall实际上是调用函数crashdmp!CrashdmpInitialize。也就是调用crashdmp!CrashdmpInitialize返回值为什么qemu返回0，而TCI返回c000000f
查看crashdmp!CrashdmpInitialize的汇编，易知分歧点在crashdmp!CrashdmpInitialize+450处，r12d在qemu是0，而TCI是c000000d(STATUS_INVALID_PARAMETER)。
4.5 第五层分歧------ZwFsControlFile返回STATUS_INVALID_PARAMETER
而r12d是ZwFsControlFile的返回值。查看此函数文档。
NTSYSAPI NTSTATUS ZwFsControlFile(
[in] HANDLE FileHandle,
[in, optional] HANDLE Event,
[in, optional] PIO_APC_ROUTINE ApcRoutine,
[in, optional] PVOID ApcContext,
[out] PIO_STATUS_BLOCK IoStatusBlock,
[in] ULONG FsControlCode,
[in, optional] PVOID InputBuffer,
[in] ULONG InputBufferLength,
[out, optional] PVOID OutputBuffer,
[in] ULONG OutputBufferLength
);
进入函数内，暂停之，解析各个入参。调用函数前的filehandle就是rcx，就是pagefile的filehandle：
crashdmp!CrashdmpInitialize+0x433:
fffff800309d38b3 48ff15eee7ffff call qword ptr [crashdmp!_imp_ZwFsControlFile (fffff800309d20a8)]
2: kd> t
nt!ZwFsControlFile:
fffff800`2a3be1d0 488bc4 mov rax,rsp
2: kd> !handle @rcx
PROCESS ffffe08c901f1040
SessionId: none Cid: 0188 Peb: 62cbe27000 ParentCid: 0004
DirBase: 14af25002 ObjectTable: ffffbb0cf1d63380 HandleCount: 51.
Image: smss.exe
Kernel handle table at ffffbb0cf1809a00 with 371 entries in use
80000550: Object: ffffe08c901e0e20 GrantedAccess: 00140003 (Protected) (Inherit) (Audit) Entry: ffffbb0cf63ae540
Object: ffffe08c901e0e20 Type: (ffffe08c8a8d2bc0) File
ObjectHeader: ffffe08c901e0df0 (new version)
HandleCount: 1 PointerCount: 32766
Directory Object: 00000000 Name: \pagefile.sys {HarddiskVolume5}
FsControlCode就是dq rsp+28h L1=0x9003B。
同样是用ZwFsControlFile处理pagefile文件，qemu环境里返回值和TCI的不同。唯一的区别点就在于二者的文件系统不同，即文件系统驱动ext2fsd.sys和ntfs.sys不同。这个函数估计是要让文件系统驱动的IRP_MJ_FILE_SYSTEM_CONTROL的派遣函数执行FsControlCode相关的处理。查看ext2fsd.sys的irp派遣函数：
!drvobj \FileSystem\ext2fsd 7
......
[0d] IRP_MJ_FILE_SYSTEM_CONTROL fffff8044b2e3560 Ext2Fsd!Ext2BuildRequest
[0e] IRP_MJ_DEVICE_CONTROL fffff8044b2e3560 Ext2Fsd!Ext2BuildRequest
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL fffff8044751e8a0 nt!IopInvalidDeviceRequest
[10] IRP_MJ_SHUTDOWN fffff8044b2e3560 Ext2Fsd!Ext2BuildRequest
[11] IRP_MJ_LOCK_CONTROL fffff8044b2e3560 Ext2Fsd!Ext2BuildRequest
[12] IRP_MJ_CLEANUP fffff8044b2e3560 Ext2Fsd!Ext2BuildRequest
[13] IRP_MJ_CREATE_MAILSLOT fffff8044751e8a0 nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY fffff8044751e8a0 nt!IopInvalidDeviceRequest
[15] IRP_MJ_SET_SECURITY fffff8044751e8a0 nt!IopInvalidDeviceRequest
[16] IRP_MJ_POWER fffff8044751e8a0 nt!IopInvalidDeviceRequest
[17] IRP_MJ_SYSTEM_CONTROL fffff8044751e8a0 nt!IopInvalidDeviceRequest
......
接受IRP_MJ_FILE_SYSTEM_CONTROL的irp派遣函数应该是Ext2Fsd!Ext2BuildRequest。在WinIoCtl.h的计算FSCTL_XXX的数值，
C
#define FSCTL_QUERY_RETRIEVAL_POINTERS CTL_CODE(FILE_DEVICE_FILE_SYSTEM, 14, METHOD_NEITHER, FILE_ANY_ACCESS)
知道0x9003B是FSCTL_QUERY_RETRIEVAL_POINTERS，功能大致是：
FSCTL_QUERY_RETRIEVAL_POINTERS控制代码检索虚拟群集编号 (VCN、文件/流空间) 中的偏移量和逻辑群集编号 (LCN、卷空间) 内的偏移量（从文件开头到 InputBuffer 中指定的映射大小）之间的映射。
FSCTL_QUERY_RETRIEVAL_POINTERS类似于 FSCTL_GET_RETRIEVAL_POINTERS。 但是， FSCTL_QUERY_RETRIEVAL_POINTERS 只能在本地分页文件或系统配置单元的内核模式下工作。 可以保证分页文件具有从卷中的 VCN 到更直接引用基础物理存储的 LCN 的一对一映射。 不得将FSCTL_QUERY_RETRIEVAL_POINTERS文件与页面文件外的文件一起使用，因为它们可能驻留在具有 VNS 到 LCN 的一对多映射的卷（如镜像卷）上。
在ext2fsd的代码中搜索FSCTL_QUERY_RETRIEVAL_POINTERS，可以找到处理函数是Ext2QueryRetrievalPointers(PEXT2_IRP_CONTEXT IrpContext)。TCI环境里动态调试此函数，其走到了这个STATUS_INVALID_PARAMETER分支：
C
FileObject = IrpContext->FileObject;/此处就是pagefile文件 /
Fcb = (PEXT2_FCB) FileObject->FsContext;
/* Is requstor in kernel and Fcb a paging file ? */
if (Irp->RequestorMode/此处是0 / != KernelMode/0 / ||
!IsFlagOn(Fcb->Flags/此处是0xa0 /, FCB_PAGE_FILE/2 /) ||
InputSize != sizeof(LARGE_INTEGER) ||
OutputSize != sizeof(PVOID))
{
Status = STATUS_INVALID_PARAMETER;//c000000d
__leave;
}
相关调用栈如下，这里的ext2fsd是个临时版本：
Child-SP RetAddr Call Site
00 fffffa08d5de6f70 fffff80735ac5f84 Ext2Fsd!Ext2QueryRetrievalPointers+0x26f [D:\Work\5-Project\ext\my-ext\Ext3Fsd\fsctl.c @ 857]
01 fffffa08d5de7040 fffff80735ac402e Ext2Fsd!Ext2UserFsRequest+0x114 [D:\Work\5-Project\ext\my-ext\Ext3Fsd\fsctl.c @ 1972]
02 fffffa08d5de7070 fffff80735a03616 Ext2Fsd!Ext2FileSystemControl+0x96 [D:\Work\5-Project\ext\my-ext\Ext3Fsd\fsctl.c @ 2926]
03 fffffa08d5de70a0 fffff807326eff79 Ext2Fsd!Ext2BuildRequest+0xb6 [D:\Work\5-Project\ext\my-ext\Ext3Fsd\dispatch.c @ 348]
04 fffffa08d5de70f0 fffff807337555de nt!IofCallDriver+0x59
05 fffffa08d5de7130 fffff8073378c190 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x15e
06 fffffa08d5de71b0 fffff807326eff79 FLTMGR!FltpFsControl+0x110
07 fffffa08d5de7210 fffff80732ca75e5 nt!IofCallDriver+0x59
08 fffffa08d5de7250 fffff80732ca73f0 nt!IopSynchronousServiceTail+0x1a5
09 fffffa08d5de72f0 fffff80732d79d96 nt!IopXxxControlFile+0xc10
0a fffffa08d5de7410 fffff80732890d15 nt!NtFsControlFile+0x56
0b fffffa08d5de7480 fffff80732883320 nt!KiSystemServiceCopyEnd+0x25
0c fffffa08d5de7688 fffff807355b38ba nt!KiServiceLinkage
0d fffffa08d5de7690 fffff80732e2c816 crashdmp!CrashdmpInitialize+0x43a
0e fffffa08d5de7870 fffff80732e2c722 nt!IopInitializeCrashDump+0xb2
0f fffffa08d5de78f0 fffff80732e2bd62 nt!IoInitializeCrashDump+0x52
10 fffffa08d5de7930 fffff80732e2b65d nt!MiCreatePagingFile+0x6fa
11 fffffa08d5de7ac0 fffff80732890d15 nt!NtCreatePagingFile+0x2d
12 fffffa08d5de7b00 00007ffdf875d6d4 nt!KiSystemServiceCopyEnd+0x25
13 000000855ccff958 00007ff6b11ea231 ntdll!NtCreatePagingFile+0x14
14 000000855ccff960 00007ff6b11ea4ec smss!SmpCreatePagingFile+0x25
15 000000855ccff990 00007ff6b11eab93 smss!SmpCreatePagefileOnVolume+0x158
16 000000855ccffa50 00007ff6b11eac2e smss!SmpCreatePagefileFromDescriptor+0x6b
17 000000855ccffa80 00007ff6b11eadca smss!SmpProcessPagefileDescriptor+0x6e
18 000000855ccffab0 00007ff6b11eb7df smss!SmpCreatePagingFiles+0x18a
19 000000855ccffb00 00007ffdf86f089d smss!SmpAsyncMemoryConfiguration+0x9f
1a 000000855ccffb40 00007ffdf86f4634 ntdll!TppWorkpExecuteCallback+0xad
1b 000000855ccffb90 00007ffdf872cedf ntdll!TppWorkerThread+0x8d4
1c 000000855ccfff50 0000000000000000 ntdll!RtlUserThreadStart+0x2f
5 结论
看来ext2fsd的开源项目本身已经预料到pagefile的问题，所以这里的注释也指明了pagefile。现在问题的关键就在于pagefile文件的fileobj的((PEXT2_FCB) FileObject->FsContext)->Flags为什么不含FCB_PAGE_FILE，或者说ext2fsd驱动为什么没有使得它包含FCB_PAGE_FILE。不知道是不是ext文件系统不存在这个概念------虚拟群集编号 (VCN、文件/流空间) 中的偏移量和逻辑群集编号 (LCN、卷空间) 内的偏移量（从文件开头到 InputBuffer 中指定的映射大小）之间的映射。我觉得这些就是下一步的研究方向。