ntdll symbols issue

NTDEV
1

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 0000000077159000 ntdll (pdb symbols) c:\windows\symbols\ntdll.pdb\9D04EB0AA387494FBD81ED062072B99C2\ntdll.pdb
fffff80002861000 fffff80002e48000 nt (pdb symbols) c:\windows\symbols\ntkrnlmp.pdb\F79084B4F72C4D508F0F4924B2AE188F2\ntkrnlmp.pdb
fffff88004513000 fffff88004520000 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 : 0x000000000001150a 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 : 0xfffffa8002b8ba60 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.

2

a short google says vadroot is at 448 not 440 as you post

http://msdn.mirt.net/win7rtm_x64.html#_EPROCESS

do !process 0 1
it will show the vadroot
do !vad

On 4/20/15, xxxxx@gmail.com wrote:
> 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 0000000077159000 ntdll (pdb symbols)
> c:\windows\symbols\ntdll.pdb\9D04EB0AA387494FBD81ED062072B99C2\ntdll.pdb
> fffff80002861000 fffff80002e48000 nt (pdb symbols)
> c:\windows\symbols\ntkrnlmp.pdb\F79084B4F72C4D508F0F4924B2AE188F2\ntkrnlmp.pdb
> fffff88004513000 fffff88004520000 MyDriver (private pdb symbols)
> c:\mydriver.pdb
>
> kd> dt 0xfffffa8001f2c810 ntdll!_EPROCESS<br>&gt; .<br>&gt; .<br>&gt; .<br>&gt; +0x438 ProcessSelfDelete : Pos 30, 1 Bit<br>&gt; +0x438 SetTimerResolutionLink : Pos 31, 1 Bit<br>&gt; +0x43c ExitStatus : Int4B<br>&gt; +0x440 VadRoot : _MM_AVL_TABLE<br>&gt; +0x480 AlpcContext : _ALPC_PROCESS_CONTEXT<br>&gt; +0x4a0 TimerResolutionLink : _LIST_ENTRY<br>&gt;<br>&gt;<br>&gt; So the _EPROCESS printout shows the VadRoot at 0x440. However, when I dt<br>&gt; the MM_AVL_TABLE at that offset, it is clearly off by 0x8.<br>&gt;<br>&gt; kd&gt; 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 : 0x000000000001150a Void<br>&gt; +0x038 NodeFreeHint : 0xfffffa8002b8ba60 Void
>
>
> kd> dt 0xfffffa8001f2cc58 ntdll!_MM_AVL_TABLE &lt;- _EPROCESS+0x448 (right)<br>&gt; +0x000 BalancedRoot : _MMADDRESS_NODE<br>&gt; +0x028 DepthOfTree : 0y01010 (0xa)<br>&gt; +0x028 Unused : 0y000<br>&gt; +0x028 NumberGenericTableElements :<br>&gt; 0y00000000000000000000000000000000000000000000000100010101 (0x115)<br>&gt; +0x030 NodeHint : 0xfffffa8002b8ba60 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.
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

3

If you read my post you would of seen I said that. And my question wasn’t “what is the VadRoot offset in Win7.” I am trying to understand why my symbols are messed up when there is no indication that they are wrong. The VadRoot is just one example where I’m seeing this problem and it is making things difficult when I try to automate some debugging tasks with my own code.

4

Can you try using nt!_EPROCESS instead of ntdll!_EPROCESS (that’s what !vad and other kernel commands use)?

I’m not even sure why ntdll!_EPROCESS exists at all.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, April 21, 2015 4:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ntdll symbols issue

If you read my post you would of seen I said that. And my question wasn’t “what is the VadRoot offset in Win7.” I am trying to understand why my symbols are messed up when there is no indication that they are wrong. The VadRoot is just one example where I’m seeing this problem and it is making things difficult when I try to automate some debugging tasks with my own code.

5

Thank you Pavel. Mystery solved. nt!_EPROCESS shows the expected offsets. So is ntdll just not updated anymore and are there other symbols that conflict with nt?

6

>a short google says vadroot is at 448 not 440 as you post

http://msdn.mirt.net/win7rtm_x64.html#_EPROCESS

In what Windows version, SP and update package?

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

7

@maxim it is said in the link it is win7rtm_x64 this link is a
mirror of the info maintained by matt suiche (moonsols) apart from
that i ve not searched anyway the op seems to have got the problem
solved by using nt instead of ntdll

On 4/22/15, Maxim S. Shatskih wrote:
>>a short google says vadroot is at 448 not 440 as you post
>>
>> http://msdn.mirt.net/win7rtm_x64.html#_EPROCESS
>
> In what Windows version, SP and update package?
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

8

If you’re working with kernel types you should get them from the kernel PDB. If some kernel type gets pulled into another module’s PDB there is no guarantee it will be the same as the real thing because the environment (#defines, struct packing options etc.) of this other module could be different.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, April 21, 2015 8:47 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ntdll symbols issue

Thank you Pavel. Mystery solved. nt!_EPROCESS shows the expected offsets. So is ntdll just not updated anymore and are there other symbols that conflict with nt?

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer