[Autogenerated] let's now open the Colonel debugger So
here's our kernel debugger I think just clear the screen
here and let's look for a job.
So one way of doing that is by finding a process which is part of a job.
For example, I can look for the W my pr v s e dot e x e instances.
In fact I'm going to change the detail level to one
because with the level of one, we get also a pointer to the job object.
This process is part of it is part of a job,
so hopefully the debugger will be able to locate the process unless the process
already has been destroyed because of the lack of activity.
Let me do that.
Maybe again launch here some w my activity just to make sure that
something would be available for us to see.
So here goes we can see the details for this process again,
just one because w my activity is not that great on this system right now,
but there's definitely a pointer to a job here and you can
see if you hover over this uh command.
The command is the job command.
The job command just like process command provides high level
information or details about the job in question.
So we have a job in this address,
we can see the accounting information shown here,
such as the Total user time.
Total kernel time and other stuff.
You can see the total processes,
that's the number that is always growing and the active processes which is
currently one and we know that this is in fact correct.
You might be wondering what are these units that are used for
total user time and kernel time which is really about the CPU
time being consumed by this job.
And so the units here are very common in the kernel in
some cases in user mode as well.
These are units with 100 nanosecond units really,
so you have to take this number and multiply that by 100 nanoseconds
which is 10 to the minus seven power to figure out how how much time was
actually spent in user time or kernel time.
And then later on you can see here um continuing the limits,
you can see the limits that are applied to this process
such as the active process limit,
you might recall it for 32 which is exactly 20 hex,
there's the breakaway, Okay limit.
Which is well actually allowing something to happen and that's the
job memory limit and the process memory limit.
And so you can see the limits here in the debugger as as you expect them to be.
But as always the command job is a high level command and behind
the scenes there is the actual data structure,
we can always dig into using the D.
T command so we can dig into that and the data structure in question
is called the job for executive job very similar in concept to
process the executive process by the way,
there is no K job in this case because the job is a high high level
object only implemented by parts in the executive So we can do that and
just see the entire data structure of a job,
which by the way,
is pretty big because jobs are fairly complex
objects and have lots of capabilities,
some of which we'll see later on in this model and some
that we'll see in the next module as well.
So there's lots of stuff here,
much more than can be viewed by the normal job command.
So what else can you do with the job command?
One other thing you can do is add some value here to
provide or to request further information.
One of them is the value to so the value two provides with the list
of processes that are part of this particular job.
So the command shows the standard job information and then list the entire
set of processes which are part of this job in this case.
Just one.
But could be more than one.
There's another thing you might want to try for fun
perhaps is to use a command called job list.
And job list is an undocumented command in the the buyer documentation,
I believe it's just an oversight on the part of Microsoft and this simply shows
the entire list of all the jobs that exist on the system.
And so all the jobs in the system are also held using a w link list,
just like processes.
And so the job list command works that list and displays and the
normal job output as part of the walking of that list.
And so this is something that you might find useful in some cases if
you'd like to explore all the jobs in the system,
you can see other details about various types of jobs,
some of them are actually silos and we'll discuss
what silos are in the next module,
but you can see all the limits that are applied here um
that are shown in one way or another,
you can always dig deep into the actual data
structure to see exactly what's going on.
So this is the job command you can use and of course
you can locate objects by name.
So for example, we've seen that there are these names to some of these objects,
some of these kernel objects that are actually jobs.
So if I go ahead and copy one of these job names,
for example, process Explorer,
we can use the object command to locate this job or this object.
Whatever the name of the object is,
you might recall that the object command is a generic command
that can locate an object based on its address.
If you have the address directly or the name of the object,
if you don't have that directly.
And so once you get that you can grab the object address and
then give that to the job command to get details about this
particular job in question.
And of course we can then use the flag to to get the of
processes that assigned to this job.
So it might seem that the result that we got here is kind of weird.
Apparently there are no processes in this job but going to the job details here,
it says that they're actually currently active
processes as two processes in this job.
So what's going on here?
Something seems to be a miss here.
And so the solution or the actual um resolution of that is
because we have here something called a nested job and we'll
discuss that later on in this module.
So this means there are likely child jobs for this job
that actually hold onto these processes.
And the way the things are being reported is that from a parent job you
can see whatever is going on in child jobs as well.
And we'll see that later on in this module.