[Autogenerated] Let's now try.
A more complex blue screen or green screen.
You can select something like buffer overflow where the my
fault cs driver will allocate memory.
And then write beyond the size of the buffer.
So if you can, if you click _____ here multiple times at some point,
the system might _____ when the buffer overflow
will write over some other buffer.
That wasn't really supposed to be written to by the driver.
And Some other components like the kernel will notice that However,
with the 64-bit address space, this is unlikely.
To happen very soon.
It really depends.
On the state of the system.
I can _____, click these _____ button as many times as I want and its some point.
It will blue screen the system.
However, I want to have something, a bit speedier.
So let's use this high R Q L fault,
which essentially would call user mode function from a high R Q L something,
that is not allowed.
Let me, crush the system.
Now, and we have the system crashing on us.
And We'll get the normal DOM file being written you can see
already the type of the DOM file here it,
is R Q L greater zero ED system,
S services So it kind of hints as to the problem,
but it doesn't show anything related.
To the actual driver, that call that kind of call So let's restart the system.
And See what we can Find out the system has restarted.
Let me launch end be G, and open the down file Here it goes.
Let's open it.
See what we get.
We get the suggestion, to launch, analyze dash V.
Let's do that and we can have some details there.
But the most important thing,
is probably looking at the call stack You can also see that the analyze H V
command blames the kernel which doesn't make much sense.
What about the call stack Well,
it's not really available directly but we can grab it using this
stack command here shown as part of the output So you can see the
call stack looks something like this.
We have anti anti anti stuff.
We do have K back,
check xss at top of the call stack But other than that there's
no hint as to why something crashed here.
Which driver was responsible for doing that We really kind of lost here.
And It's also not very easy.
To figure out what is this address here its a user mode address obviously,
we can Of course, look at the current process by using process -10.
To see which one uh is initiating that request that would be this process which
already gives us some hint as to who might be responsible.
But still we don't see any kernel component here other than the kernel itself.
So how can we figure out what is going on?
So, one very useful tool you might want to use in see In such difficult cases,
we don't see the culprit directly on the call Act,
is called Driver Veri file which I'll introduce to You next.