[Vol-users] Why doesn't memmap tally with vadinfo?

Michael Ligh michael.ligh at mnin.org
Fri Oct 16 10:32:29 CDT 2015

Hash: SHA512

Hey Adam,

> Is it the case that the VAD node is responsible for the whole
> range, but simply not all the pages in that range are in use which
> is why they're missing from the memmap output?

Yes, that's precisely why. For example, you can call VirtualAlloc(1GB,
MEM_RESERVE) and it will create a VAD node describing 1GB of process
memory...but until you go back and specify MEM_COMMIT, no physical
pages will be mapped and thus nothing will show up in memmap.

Also, the VAD's CommitCharge /should/ tell you the number of pages in
the VAD range that have been committed. In your example its:

CommitCharge: 5

So that means 5 pages are available to the process. I don't know why
you see 13 of them. From my understanding, the CommitCharge increases
by 1 for every page in the range that's committed (and thus available
to the process).


On 7/7/15 1:29 PM, Bridgey theGeek wrote:
> Hi all,
> System is Win7SP1x86. pagefile is OFF.
> Consider this VAD node (from vadinfo):
> VAD node @ 0x85e076d0 Start 0x76440000 End 0x764dffff Tag Vad 
> Flags: CommitCharge: 5, Protection: 7, VadType: 2 Protection:
> PAGE_EXECUTE_WRITECOPY Vad Type: VadImageMap ControlArea @853ab1e0
> Segment 8f6eba98 NumberOfSectionReferences:          1
> NumberOfPfnReferences:         120 NumberOfMappedViews:
> 32 NumberOfUserReferences:         33 Control Flags: Accessed: 1,
> File: 1, Image: 1 FileObject @853ab898, Name: 
> \Device\HarddiskVolume1\Windows\System32\advapi32.dll First
> prototype PTE: 8f6ebac8 Last contiguous PTE: fffffffc Flags2:
> Inherit: 1
> My understanding is that this VAD node is tracking the pages from 
> 0x76440000 through to 0x764dffff.
> When I look at the output of memmap for this process and this range
> I see: --SNIP-- 0x76228000 0x1f04c000     0x1000       0x2c1000 
> 0x76440000 0x20670000     0x1000       0x2c2000 <-- start 
> 0x76441000 0x0b728000     0x1000       0x2c3000 0x76451000
> 0x233a8000     0x1000       0x2c4000 0x76454000 0x1f5ab000
> 0x1000       0x2c5000 0x76455000 0x2336c000     0x1000
> 0x2c6000 0x76456000 0x1f6ed000     0x1000       0x2c7000 0x76457000
> 0x1f6ae000     0x1000       0x2c8000 0x76458000 0x2346f000
> 0x1000       0x2c9000 0x76459000 0x1e48b000     0x1000
> 0x2ca000 0x7645a000 0x21fcc000     0x1000       0x2cb000 0x7645b000
> 0x223cd000     0x1000       0x2cc000 0x76460000 0x1e3d2000
> 0x1000       0x2cd000 0x76461000 0x1e103000     0x1000
> 0x2ce000 0x764af000 0x20636000     0x1000       0x2cf000 0x764b1000
> 0x23ef8000     0x1000       0x2d0000 0x764b3000 0x0bded000
> 0x1000       0x2d1000 0x764b7000 0x1f730000     0x1000
> 0x2d2000 0x764e0000 0x208e6000     0x1000       0x2d3000 <-- first
> byte after end --SNIP--
> The file itself, advapi32.dll, is 0xa0000 bytes (well, in memory). 
> dlllist shows: Base             Size  LoadCount Path ----------
> ---------- ---------- ---- 0x76440000    0xa0000     0xffff
> C:\Windows\system32\ADVAPI32.dll
> 0x76440000 through to 0x764dffff is 0x9FFFF bytes long. However,
> memmap is only showing 0x13000 bytes.
> The 0x13000 isn't big enough to hold the 0xa0000 bytes of the
> file.
> My question is, why isn't the whole range (0x76440000 through to 
> 0x764dffff) shown in memmap?
> Is it the case that the VAD node is responsible for the whole
> range, but simply not all the pages in that range are in use which
> is why they're missing from the memmap output?
> Or is there something that I'm missing?
> Any comments greatly appreciated!
> Adam
> _______________________________________________ Vol-users mailing
> list Vol-users at volatilityfoundation.org 
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
Comment: GPGTools - https://gpgtools.org


More information about the Vol-users mailing list