[Autogenerated] Let's now test the application.
The first thing we need to do is to get some kind of command
line interface here so we can work with whatever we have here
and use the command line for that.
So there's a developer PowerShell here that appears inside visual studio.
But of course we can use an external command window or the
Windows terminal whatever you prefer.
Doesn't really matter that much.
Let's just use the normal command window to make sure
that it's as as common as possible.
So we have the jobs project solution here really and here's
the executable here called CPU limit.
If I just use that we get the information that really I
need the CPU limit to be provided.
The process I.
D.
And some percentage.
So in order to test that we need some implication that consumes lots of CPU.
So fortunately I have one of those, it's called CPU stress.
And CPU stress is also this internal tool that I've written a few years back but
there's a newer version you can use for my data repository.
It's also available in the downloads for this module.
So the purpose of CPU stress is to well burn CPU cycles
and no it's not a very lofty goal.
But sometimes this is useful.
So what I'm going to do here, they can see their four threads.
I'm going to select these three threads,
make them active and have them do maximum activity with maximum activity.
They are running all the time.
They're burning CPU cycles all the time if you open task manager Just
to see what's going on and focus on CPU stress.
You can see the CPU stress now consumes 37.5 CPU percentage
roughly give or take 38 doesn't really matter.
But assuming that they have eight processors on my system,
three of them should be busy all the time.
So these things should consume roughly 37% of CPU It's not what I want to do,
I would like to change that to something smaller,
let's say 15%.
So here's how we need to make that work.
So I'm using CPU limit here.
We need to process I.
D.
Which we can get from process for task manager here.
Process Explorer or in fact it is shown on the title bar of CPU stress.
So let's do that.
11468 and the percentage of choice,
let's just go with 15 for demonstration purposes and it entered,
You can see it says success and you notice the CPI consumption
has indeed been documented to roughly 15%.
So you notice that it's not exactly 15% all the time.
It's uh it's oscillating around this 15% number and there are a few reasons
for that first task manager is only updated once a second.
And secondly the way this works behind the covers is that there are these
300 millisecond time windows in which the kernel tracks to see how much CPU
consumption has been used in that window and then if too much is used then
it's going to suspend those threads or the proper threats in the next 300
millisecond window so that on average it's going to be roughly the num That
we ask it to be.
So we have indeed 50 15% here roughly.
And you can see it was very easy to do without us having
to work very hard to get that in play.
So let's see what the tools have to say about that.
So let's start with process explorer going to the CPU stress tool and you
can see here that CPU stress indeed is under a job.
Let's double click that you can see the name of the job as I provided it.
Well, almost I just gave the name.
CPU limit job However you can see here there's a prefix and that prefix has to
do with the fact that by default names are session relative.
So they're part of sessions.
Session number two,
which is one I'm using here logged in remotely and base named object
as a constant fix string and then the actual name.
I'll explain why these names or why these session relative
names are necessary in the future course.
And we see some another example of that in the next module when we discussed
silos but again the name here is just for identification purposes don't
really needed for the actual activity of the job.
So notice the CPU stress is the only process in the job and indeed
it has the correct process ide here but you know,
there are no limits here.
And as I mentioned,
the current version of process explorer doesn't show
limits that are related to limits that have been created
Windows eight or later time frame.
So we're kind of out of luck here for CPU rate limit However,
if you go to system Explorer, my own tool here.
So for CPU stress we can see that indeed it's part of
the job and clicking the job here,
we can see the correct number here shown as the limit.
So first we can see the flag of hard cap indicating that the hard cap flag is
active and the CPI rate limit is 1500 which is exactly the number we have placed
into the actual uh parameter for such information job object because we know we
have to multiply the actual percentage we want by a factor of 100 that's why we
have 1500 here as the value.
You also notice that in terms of basic information,
the total CPU time,
kernel and user time is growing steadily because the
process is active within that job, it's currently the only process in this job.
So at least we get some verification here that what we are
trying to do is actually right and working as expected not just
from an observational perspective, but also from what the tools have to say next.
We might want to look at the kernel.
debugger Okay,
so now let's grab the Colonel debugger here and see what debugger has to say let
me clean this up a little bit and we want to find the job,
we can use that by name,
we can find the process so we can find the process in question.
We know the process is 14 so 14164 11468.
That's the process I.
D.
So let's look for that and use the detail level of one because
that's the one that shows us also the job pointer if we have any and
we do so here's job and I'm clicking that and you'll notice we get
some information about the job, that's the stand information we've seen already.
Obviously it says CPI rate control is currently in effect,
you can see that it acknowledges that and so we have CPI rate control details.
However you'll notice the rate is 0% which again is a bug in the debugger and
that's because the debug currently uses private symbols to figure out the CPI
rate control and private symbols for for what we need here for the kernel
modules are only available if you are working within Microsoft and because I
am not we don't have here, the full the full result,
we just see zero.
So just I wanted to warn you About that so that you might not think that well
maybe I have a bug in my program and and so you don't you don't necessarily
have a bug you always see 0% for CPU rate control.
The scheduling group is an internal object that is used for
managing the CPI rate control feature.
Something that we will not be discussing in this course.
So we get something but definitely not everything.
So currently,
the only tool I know is is this tool system Explorer
that provides the correct details.
The next version of process Explorer will provide the
correct details as well when that's out.
Maybe it is already out at the time you're watching this video.
And so that's what we can see with tools.
Of course,
you can do this uh kind of step by step by using the debugger And you
might be wondering why have I used sleep infinite here.
And so that was just because once we do a control C here and
and terminate the CPU limit the actual uh parent process that
applied and controlled that joe Job, nothing actually changes.
So you can see the CPU stress tool is still limited to 15% on average.
So that's not going to change.
Like I said,
it's not necessary to keep track of the job because the
process itself actually references the job.
However, if you try to look at the name of the job for instance,
you'll find that the name is gone because the last handle to the job was closed.
So the job is in a in a mode of pending delete.
It's actually it's going to go out.
And the only reason it's still alive is because that CPU limit application.
Sorry the CPU stress process is still alive and that's the
only thing that keeps this job alive.
That's the likely scenario here.
And of course we can and we can make sure just by going to debugger again.
So we have this job object.
So now instead of using the job command,
let's use the object command to get some generic details here,
you can see that we have zero handles, zero handles to the job.
The job is almost out.
However,
there's still one reference count and that reference count
is held by the CPU stress process itself.
You can see the name is still known but the
directory object into which is stored.
That's the sessions to based on logic you've seen
earlier is no longer being tracked.
So it's no longer there in any given um another kind of way and
that's why it's not really discoverable anymore.
So there's a reference that is still there and once we
kill CPU stress this is going to go away.
So here's CPU stress.
Let's kill it.
And now if I try the same thing,
I may or may not get something and you can see that the memory has not yet
been replaced by other data or by different objects.
So some things are still accessible in exactly the same way
But obviously the name has been freed.
So now we have something here which is not accessible,
and later on this might be even replaced by a completely different object.
You can see it has been replaced for some for some other
data structure the kernel is using.
This is no longer exactly showing us perhaps what we expect,
but that's fine and this is what we expect.
The object is no longer alive,
although the memory is still showing us what was there,
except for the name,
which was explicitly free because it is allocated dynamically.