The crux of my issue is that the symbol offset for _EPROCESS->VadRoot seems to be off by 0x8 in all of the pdb files I am getting from the MSFT symbols server.
First I’m on a Win7 x64 box debugging a Win7 x64 VM. Both have ntdll.dll version 6.1.7601.18247, 8/28/2013.
kd> .reload
Connected to Windows 7 7601 x64 target at (Mon Apr 20 12:47:02.729 2015 (UTC - 4:00)), ptr64 TRUE
DBGHELP: nt - public symbols
c:\windows\symbols\ntkrnlmp.pdb\F79084B4F72C4D508F0F4924B2AE188F2\ntkrnlmp.pdb
Loading Kernel Symbols
…
…
…
…
Loading User Symbols
…
Loading unloaded module list
…
DBGHELP: ntdll - public symbols
c:\windows\symbols\ntdll.pdb\9D04EB0AA387494FBD81ED062072B99C2\ntdll.pdb
.
kd> lml
start end module name
0000000076fb0000 00000000
77159000 ntdll (pdb symbols) c:\windows\symbols\ntdll.pdb\9D04EB0AA387494FBD81ED062072B99C2\ntdll.pdb
fffff80002861000 fffff800
02e48000 nt (pdb symbols) c:\windows\symbols\ntkrnlmp.pdb\F79084B4F72C4D508F0F4924B2AE188F2\ntkrnlmp.pdb
fffff88004513000 fffff880
04520000 MyDriver (private pdb symbols) c:\mydriver.pdb
kd> dt 0xfffffa80`01f2c810 ntdll!_EPROCESS
.
.
.
+0x438 ProcessSelfDelete : Pos 30, 1 Bit
+0x438 SetTimerResolutionLink : Pos 31, 1 Bit
+0x43c ExitStatus : Int4B
+0x440 VadRoot : _MM_AVL_TABLE
+0x480 AlpcContext : _ALPC_PROCESS_CONTEXT
+0x4a0 TimerResolutionLink : _LIST_ENTRY
So the _EPROCESS printout shows the VadRoot at 0x440. However, when I dt the MM_AVL_TABLE at that offset, it is clearly off by 0x8.
kd> dt 0xfffffa8001f2cc50 ntdll!_MM_AVL_TABLE \<- _EPROCESS+0x440 (wrong) +0x000 BalancedRoot : _MMADDRESS_NODE +0x028 DepthOfTree : 0y00000 (0) +0x028 Unused : 0y000 +0x028 NumberGenericTableElements : 0y00000000000000000000000000000000000000000000000000000000 (0) +0x030 NodeHint : 0x00000000
0001150a Void
+0x038 NodeFreeHint : 0xfffffa80`02b8ba60 Void
kd> dt 0xfffffa8001f2cc58 ntdll!_MM_AVL_TABLE \<- _EPROCESS+0x448 (right) +0x000 BalancedRoot : _MMADDRESS_NODE +0x028 DepthOfTree : 0y01010 (0xa) +0x028 Unused : 0y000 +0x028 NumberGenericTableElements : 0y00000000000000000000000000000000000000000000000100010101 (0x115) +0x030 NodeHint : 0xfffffa80
02b8ba60 Void
+0x038 NodeFreeHint : (null)
I’ve even looked at the pdb file in a hex editor to verify the offset that WinDbg is telling me.
00 00 40 04 56 61 64 52 6F 6F 74 …@.VadRoot
What I don’t understand though that that when I use !vad, WinDbg prints the VAD table properly.
kd> !vad fffffa8001a38430
VAD level start end commit
fffffa8001db0bd0 ( 6) 10 1f 0 Mapped READWRITE Pagefile-backed section
.
.
.
Total VADs: 277, average level: 7, maximum depth: 9
If WinDbg was reading the NumberGenericTableElements based on the symbol offsets it would be zero instead of the proper 0x115 (277) like it is listed here. But I would think if it is just iterating through the VAD tree using the wrong offsets, it would produce the wrong values. So obviously I am missing something here but I have no idea what. Any insight would be appreciated.