Windbg vtop outputs physical address larger than memory

Question

I'm studying the internals of the Windows kernel and one of the things I'm looking into is how paging and virtual addresses work in Windows. I was experimenting with windbg's !vtop function when I noticed something strange I was getting an impossible physical address?

For example here is my output of a !process 0 0 command:

PROCESS fffffa8005319b30
    SessionId: none  Cid: 0104    Peb: 7fffffd8000  ParentCid: 0004
    DirBase: a8df3000  ObjectTable: fffff8a0002f6df0  HandleCount:  29.
    Image: smss.exe

when I run !vtop a8df3000 fffffa8005319b30. I get the following result:

lkd> !vtop a8df3000 fffffa8005319b30
Amd64VtoP: Virt fffffa80`05319b30, pagedir a8df3000  
Amd64VtoP: PML4E a8df3fa8
Amd64VtoP: PDPE 2e54000
Amd64VtoP: PDE 2e55148
Amd64VtoP: Large page mapped phys 1`3eb19b30
Virtual address fffffa8001f07310 translates to physical address 13eb19b30

The problem I have with this is that my VM that I'm running this test on only has 4GB and 13eb19b30 is 5,346,794,288...

When I run !dd 13eb19b30 and dd fffffa8001f07310 I get the same result so windows seems to be able to access this physical address somehow... Does anyone know how this is done?

I found this post on Cheat Engine that looks like he had a similar problem to me. But they found no solution in that case either

Answer 1

So I think I was finally able to come with a reasonable answer to the problem. It turns out that vmware doesn't seem to actually expose to the VM contiguous memory but instead segments it into different memory "runs". I was able to confirm this by using the volatility:

$ python vol.py -f ~/Desktop/Win7SP1x64-d8737a34.vmss vmwareinfo --verbose | less

Magic: 0xbad1bad1 (Version 1)
Group count: 0x5c

File Offset PhysMem Offset Size      
----------- -------------- ----------
0x000010000 0x000000000000 0xc0000000
0x0c0010000 0x000100000000 0xc0000000

Here is a volatility github wiki article that goes into more detail about: volatility

Answer 2

I see You have posted this is RESE also i saw it there didn't understand exactly what you are trying to do.

i see a few discrepancies

you seemed to have used a PFN a8df3000 but it seems windbg seems to be using a PFN of 187000 instead

btw pfn iirc should be dirbase & 0xfffff000

also for virtual address you seem to using the EPROCESS address of your process
are you sure that this is the right virtual address you want to use ?

also it seems you are using lkd which is local kernel debugging prompt

and i hope you understand that lkd is not real kernel debugging