[Autogenerated] the last topic I'd like to discuss in this module is the
data structures used by the kernel to manage processes.
Most of them are in kernel space, but there's at least one in user space,
which the colonel doesn't really care about too much,
but still something that is worth knowing about.
So first in the kernel there is a data structure called the process
short for executive process which represents and handles and managers
everything there is to know about that process.
It has many members, some of them have the information directly within them.
Some of them are pointers to other data structures that
contain the rest of the information.
But everything about the process can be obtained by
starting from the process data structure.
Now,
the first member of an e process data structure is of type
K process short for Colonel Process,
you can think of that as having these two layers that we've seen in the previous
course where we had this Colonel and executive two layers,
at least logical layers in the kernel.
Second thing of that is similar to the way the process is built.
It has a K process structure which is mostly interesting for the kernel,
the lower level kernel that handles things such as spread scheduling
and then there's the other parts of the structure of the process
which contained the rest of the information And so the one thing that
is always guaranteed is that the first member of an E process is of
type K process and has the name PCB showed for process control block
in general.
The process structure is not properly documented.
The Windows driver kit or anywhere else in an official capacity and
its members sometimes move around and that's why we can't really
rely on the layout of the structure,
although it is fully available in the symbols as we'll soon see.
The only thing we can rely on is that the first member of
an process is always the K process, essentially they're both in the same address.
In addition,
all the processes in the system are managed in a w linked list
and I'll show you this list in the next demo,
but all the processes are there listed in this circular
linked list and it's possible to perform some kind of
iteration if some code desires to do that.
In fact every process enumeration function that you may or may not be
familiar with eventually does that kind of iteration to figure out
which processes exist in the system And we'll see that the chain is um
is actually managed by a data structure called list entry And the
member within the process that changed the next And the previous
process is called Active process links will feel that in the debugger
in the next demo, the root of this linked list is a kernel variable called PS.
Active process head,
which we can get access to as well and in user mode there's
another data structure that is often used,
which is called the process environment block or PB,
which is yet another undocumented data structure and mostly the members
there are not really provided officially by Microsoft,
but this structure has been reverse engineered quite a bit.
So we pretty much know what it actually holds and some small
parts of it are in fact lightly documented within the
migrants of documentation somewhere.
So we'll see what the PB holds and we also understand why we have the
process environment block where we have used the mod stuff.
So why do we have that kind of split?
Why do we have stuff that is in kernel space which obviously is
necessary to protect the access and management of a process.
But then we have that PB the process environment blocking user space
and would like to understand why we have that there.
So let's see what that looks like in the kernel debugger and use um oh,
debugger as well.