Says the PDPT and PDs of the process are at the same physcial frames (pfns) in both processes.
The first process is
winword.exe and the second process is
The virtual address in the first case is the start of the virtual page containing the header of
winword.exe, which VMMap shows to be in the shareable working set, but yet the output shows that the entry in the PDE hasn't ever even been touched.
I then try that virtual address in
calc.exe, where VMMap shows no VAD allocation to that range, and it shows the same identical output.
This suggests to me that !pte is showing me the output of some other process, and I can't change it away from that and using
.process alone and
.context with the correct dirbases (cr3/PML4 physical pages) doesnt work.
kd -kl, not
This also happens in
windbg. Furthermore, I get the same pfns for both outputs, and those pfns change to a new set every time I reopen the debugger, which suggests that it is using the debuggers context. Is this a limitation with local debugging? I would have thought that a kernel driver would be able to do this correctly.
process /p does nothing, and
!peb correctly shows the different PEBs of the 2 different processes, but
!pte still appears to be using the context of
!vtop appears to be working correctly:
The problem is reproducible also on
windbg (version 6.12) and also I tried version 10. This seems to be related. So does this (dreadful answer).
I translated the virtual address to the virtual address of its PTE using this technique (which is of course the same address that was attempted to be shown in the
!pte output, and will be the same PTE address for that virtual address in the context of every process) and
db shows nothing at that address either:
You still need to select the process context because the user side of the page tables as well as PML4 are mapped in differently for each process.
db lines up with new state of
0x13fe60000 according to
!vtop works correctly:
I mean, the difference is that
!vtop is accessing physical memory whereas
!pte access virtual memory.
!peb works correctly and accesses virtual memory, but is user mode. It seems that it is struggling with reading kernel virtual addresses.