kd live local debugging !pte and db don't work (only shows context of the debugger for all contexts), but !vtop works

Question

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 calc.exe

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 .process + .context with the correct dirbases (cr3/PML4 physical pages) doesnt work.

I'm using kd -kl, not livekd.

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 kd

!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 !pte:

but !vtop works correctly:

I mean, the difference is that !vtop is accessing physical memory whereas !db and !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.

Answer 1

https://microsoft.public.windbg.narkive.com/3twYsQJV/i-can-t-set-process-context

This person also noticed the issue and also came to the conclusion that it is showing the context of the debugger. He then said that it works on livekd ironically, which I can confirm.

Finally.

Although, this doesn't explain why livekd works and why kd -kl doesn't, which is what I actually want to know

Answer 2

@blabb 's link is the correct answer for local debugging

Debugger cache is used only for live targets, local kd doesn't really need it. However, local kd still needs to decide how to translate virtual addresses to physical ones when you switch to a process. This is where the different .process options come into play:

.process: No translation is performed. All memory accesses are performed in the context of debugger's process. Kernel memory which is valid in any process context (pool, system PTE mappings etc.) will be displayed correctly, everything else (user memory, session space, page tables etc.) will not.

.process /p: User addresses are translated using the page directory of the specified process, so commands like !peb should work correctly. Kernel addresses are not translated, so things like session space and page tables may still be displayed incorrectly.

.process /P: All addresses, user and kernel, are translated. Use this option if you need to look at session space, page tables or other process-specific data in the kernel space.

I did not think it would be a bug -- the functionality to do it was clearly available. There has to be a specific usage to account for how local debugging works compared to livekd.