[Autogenerated] Let's start with Task manager going to
the performance tab in task manager.
We can see in the memory area there is some information indicating
how much memory is stored in the kernel pools.
So currently you can see the actual size is 704 megabytes for the
page pool and 289 megabytes for the non page pool.
That now number indicates the amount of RAM being used by the non page pool
because non paged pool by definition is always mapped to physical memory is
never paged out the page Pool on the other hand,
704 megabytes is the current size of the page pool,
some of which might be in physical memories,
some of which might be paged out to get some more
details as to what's going on in the pool.
I'm going to use a tool called pullman X version two,
which is the tool I've written a few years ago.
There's another tool that provides similar information called pullman,
which is part of the Windows driver kit,
but it's not a graphical tool,
it's a textural tool and not as easy to use or as convenient.
So I have here this tool that shows all these allocations based on these tags.
So you notice that these tags are always asking characters.
In fact,
this is a requirement when using something like the driver verifier tool when
writing kernel drivers and getting some kind of verification.
This is kind of necessary.
Again, the tax themselves don't mean anything on,
don't have any kind of effect as to what's going on in the
system but they are used to tag these various allocations and
are very helpful in terms of debugging.
You can see here in the source and description will get some
information about what these tags are actually used for.
And this information is extracted from the pool
tactics file that I mentioned earlier.
What I've done here in the tool have passed a certain version
of pull tactics and then assign these descriptions and sources
based on the tags that can find.
And I'm updating this information every second.
It's possible to sort here by tag if you so desire.
It's also possible to sort by the usage page or non page pool.
So for example,
for the page but you can see the most amount of memory
being used is by this stack called mm S T.
You can see the source is N T mm,
which means the memory manager within the executive and it's talking
about something called section object prototype.
Pts.
The exact meaning of that is not important for our purposes here.
The next one is called F M F N which is used by flt MGr dot c,
which is the file system in filter manager in Windows and is used
specifically for these kinds of structures.
So essentially any kernel component or device driver can use one or
more tags to tag its allocations for for debugging purposes or for
at least tracing and getting a sense of how much memory is being
used from the memory pools.
So these are page stuff.
We can go to the non page as well.
For example,
you can sort by non page pool to see who is using
the most non paged pool memory.
And currently this is E T W B.
That's the name of the tag which is used by event tracing
for Windows component within the kernel,
for storing or using e T W buffers, event tracing for Windows buffers.
So you can get a sense of memory usage here.
Just by looking at this tool which is updating every second or so.
In order to see the actual more specific allocations,
you have to go into the kernel debugger So with the
current debugger you can use the pool tag,
for example, or pull find commander, A few commands you can use with pool find,
you might locate all possible um, allocations but to be more specific,
you can specify the tag that you're interested in.
So for example, if you're interested in this tag,
et W B,
we can just write it out and let the debugger find all allocations
that are being tagged using this particular tag,
obviously this might take some time because it has to scan potentially
lots of memory but if everything goes as planned,
if they are in fact these tags are actually being
used or this particular tag is used, then you can find these allocations,
you can see here, the address of the particular location,
the same tag of course as we requested and the size of that particular
allocation and from each pool this allocation is and we know that this tag is
only at least at least it used for non page four locations.
This is what we get.
And then of course you can go ahead and just grab an
address that you might be interested in.
Just look at that using the normal display commands for whatever purpose,
depending on what you're trying to do.
So this is colonel memory in terms of data code is just code obviously,
so it's perhaps more understandable.
Some of the code such as interrupt dispatch routines are
always going to be in physical memory,
you can get a quick sense of that by using the I D T command
that shows the interrupt dispatch table.
Again that interrupts in general are beyond the scope of this particular course,
but you can see here some functions here so all these functions you see here,
they're going to be invoked by virus interrupt are always in physical memory.
This is necessary in because of the way interrupts work,
where the architecture of the process stories high and cannot be in
corrupted unless the even higher r Q L comes along or higher
interest comes along to be more precise.
So these functions will never be paged out.
They always have to be in physical memory and this is just normal code.
You can examine using the normal You command for an
assembling or disassembling code