[Autogenerated] Back in our kernel debugging session.
We're still debugging, that Windows 11 virtual machine,
and We're at the start of that inter, app service routine for the timer.
So I expect that inter, up service routine at some point.
To quotes order for that to be performed as soon as possible.
Once the R Q L starts to drop-down or drops down to two obviously,
that would be the most common case.
That would be happening immediately.
So let's see if we can set up a break point for K insert QD,
PC which is the API to use to Actually QD PC.
So let's put a break point here.
And continue running.
And I expect that to heat very quickly.
However, you can see that We're hitting the same break point again.
Yet another timer,
that is happening on a different processor which of course could be the case.
So instead what we'll do is just disable the first break point.
And then continue running.
So we hit the insertion of the D PC.
And again.
We, we get another one.
Just as a as a spurious breakpoint.
Let's continue.
Well, apparently, these breakpoint, is so powerful,
we can't really um disable it.
Completely.
Let's see if we can remove that entirely.
So eventually we managed to get uh to that break point.
Apparently the debugger is perhaps uh a bit confused, and still continues.
To to provide uh a break instruction inside the uh internet up service routine.
But at some point, we get to insert, Q DPC.
Let's see what's going on on the call stack here.
So we can see that this is happening for a different
interrupt altogether but still interrupt.
Is an interrupt.
You just want to be able to see something,
that is happening in terms of these D, PCs So D PCs about to be key,
coded into the QE it, is again, happening on some process but again,
this is a random process.
We shouldn't, we shouldn't conclude anything out of that apparently.
These these the uh MP engine, the the engine, four for defender.
In any case, uh We have es Q, DPC, and the first parameter, is the DPC itself.
So we can look at that DPC, that would be a structure called KD PC.
And the variable is the first parameter.
We know that's in the R, cs register.
So that's the D PC, and this is the function that's supposed to be called,
it's called the third routine.
So technically, we can put a breakpoint here at this point.
By the way, the arc code should be something.
Well, it could be anything depending on the interrupt currently being serviced.
In this case, it's three that's fine.
But if we go ahead.
And set up, a break point, in the that call back routine.
The deferred routine where the D PCs actually going to be executing.
We expect the R Q to be two Once we get to that routine.
So let's do a go Here we get another K insert Q D PC,
these things are happening all the time.
And Since I have multiple processors.
Things are happening concurrently.
Notice this is happening on a different processor.
So again, I'll try to disable everything except for for what we have here,
which is uh handling, that particular DPC or handling,
that particular request and So we get indeed into that break point,
eventually, and If you go ahead and look at what's going on here.
And look at the R R Q L, the R Q L should be level number two,
and it, is In fact, level number two here So you can see that Indeed,
we managed to to be inside a DPC routine,
and So it is coming from this function.
Caret D PC list,
which I mentioned on the slides which is the one that's doing the
processing essentially sitting in a loop where while the DPC Q,
is not empty, and pulling, these D, PCs out,
and just running each one in turn doesn't really care what its running.
Its simply going to run those by the way it.
Is probably the case.
That these Previous inter apps that we've seen with the timer
happened because they were kind of queued up.
And then They started to kind of burst.
Once we let the machine go so it is Definitely possible
when you do four channel debugging,
to Dig deeper into what's going on in D PCs that You
might care about to interrupt, service routines you might be interested in.
So this is definitely uh very convenient for research purposes.
At the very least.
There's one more thing.
IDE like to Show you.
let me remove all the break points here.
And Let the target continue execution.
Let's connect to it, and One of the things you can look at.
Is task manager in task manager, you'll find there.
Is a process,
that has the processed idea of non existent called here system interrupts.
In fact, the purpose of these pseudo process.
This is not a real process, is to account for the time processors.
Are spending at attack co two or higher you can see here,
in the description, it, says deferred procedure calls,
and inter, up service routines, but a bit,
more precise would be to say that any code running,
attack two or higher is going to be accounted here by this CP activity.
You can also look up the same information in process explore which is more
accurate providing fractional values for that percentage.
So on a typical system, you expect this to be around 1 1%, 2%,
3 3 percent,
depending on the amount of interrupts or number of interrupts happening.
If you have lots of eye operations.
For instance, you would have lots of interrupts.
And then lots of DPC S which means more time will be spent at arc two or higher.
However, if the numbers, are really big,
like 10%, 20%, 30 even higher than that for a considerable amount of time.
Then something, is probably wrong.
Its either some bug in a kernel driver,
or perhaps even some hardware bag because remember
that with these high R R Q L S, user mode code is definitely not running.
So this shouldn't really get to these kinds of numbers.
But that's the purpose of this pseudo process.
To Give us a sense of how much time.
Is spent handling interrupt, and D,
PCs or to be more precise any code environment target,
two or higher which usually is DPC S, and I S R S