VAD List

NTDEV
1

All :

Is there any Undocumented or Documented ( but, reliable :wink: ) method to
Enumerate all the memory allocation for each Process ? This is basically to
intercept some of COM Interfaces. I have seen some of Sample in Kernel(To
enumerate VAD List), but its better if I get in Userland.

(I know, Hooking API or anything is not good. But, most automation tools
will not exists in Market without hooking things, Since OS doesn’t ( or cant
) give everything People want ).

Any ideas, clue’s, etc… :slight_smile:

Regards,
Satish K.S

2

> Is there any Undocumented or Documented ( but, reliable :wink: )

method to
Enumerate all the memory allocation for each Process ?

Look at the Win32 VirtualQueryEx() function.
Using this function should be enough to get a status of
the whole virtual address space of a process.

Dmitriy Budko
VMware

3

Dmitriy Budko :

Thanks. I got utility which scans all these, but looks like If I have
something like :

Char *Ptr = new char [100] ;

It doesn’t list in this list ?

Basically, I need all memory allocations starting address including size.

Regards,
Satish K.S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dmitriy Budko
Sent: Wednesday, November 10, 2004 1:23 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] VAD List

Is there any Undocumented or Documented ( but, reliable :wink: )
method to
Enumerate all the memory allocation for each Process ?

Look at the Win32 VirtualQueryEx() function.
Using this function should be enough to get a status of
the whole virtual address space of a process.

Dmitriy Budko
VMware

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

New goes through the c runtime’s allocator, which probably does slab
allocations from either the heap or the system API - allocating large
blocks of memory and then splitting them up internally for better
performance.

Likewise the heap can do slab allocation using the system API.

From the kernel side you’re only really going to see allocations done
through the system API (the VAD list). You won’t be able to see how the
heap or CRT allocators have broken things up.

Knowing how memory was allocated wouldn’t help a driver do anything that
it needs to do anyway. In general a driver doesn’t need to be concerned
with any details beyond “is the virtual address range accessible” -
whether some user-mode allocator has then subdivided the block is
irrelevant.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Int3
Sent: Wednesday, November 10, 2004 1:36 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] VAD List

Dmitriy Budko :

Thanks. I got utility which scans all these, but looks like If I have
something like :

Char *Ptr = new char [100] ;

It doesn’t list in this list ?

Basically, I need all memory allocations starting address including
size.

Regards,
Satish K.S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dmitriy Budko
Sent: Wednesday, November 10, 2004 1:23 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] VAD List

Is there any Undocumented or Documented ( but, reliable :wink: ) method
to Enumerate all the memory allocation for each Process ?

Look at the Win32 VirtualQueryEx() function.
Using this function should be enough to get a status of the whole
virtual address space of a process.

Dmitriy Budko
VMware

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com