[Autogenerated] So he would like to use driver,
Veri far to try,
to locate a bug in a driver with suspect before it
actually crashed the system in a generic way.
So first, I'm going to Launch not my fault, just to force my fault.
Dot CSS driver, to load and that would make it easier.
To locate later on and then I'm going to Launch the driver
verifier which can be done using the command line simply by
typing verifier the executable itself, is in the system,
32 directory 32 launches.
It has a wizard, like user interface,
first we can select some options such as create the standard settings,
the standard setting, is just a set of checks,
that are considered standard which Microsoft always uses
for its own testing we can do something,
a bit, more specific by checking this option.
And saying I would like to be more specific and select the exact test,
IDE like to apply for the drivers, IDE like to test,
and of course, we can delete existing settings.
If there are any display the current settings.
If there are any and some information about currently monitored drivers.
Can be provided by using these option.
Just for demonstration purposes.
Let me just click create here with the uh custom settings option,
and click next here.
You can see the set of tests.
That are available.
To choose from and The flag type indicates whether that particular test,
is part of the standard set or an additional extended set.
When we select the standard set here by using the first option, in the wizard.
It in fact, selects all the options.
That are here marked as standard.
So let me give you a couple of examples.
One of them, is special pool special pull means that every time,
that particular driver driver, is being tested,
allocate memory, they allocate that from a different location in memory.
That doesn't mix with other buffers allocated by other drivers or the kernel
which means that If that kind of driver overflows the buffer,
the blue screen, is immediate,
and that driver will be the culprit on the call stack rather than
overwriting some data and If some other component happens,
to see that malicious or bad data it will _____ the system
but the original driver will no longer be anywhere on the
call stack So that's one option, another option,
is to provide something like randomized low resources simulation.
The idea here,
is that You can tell the kernel that for this particular driver or drivers.
Any time they make an allocation.
If, if it's a small one randomly fail these allocation,
just to see how the driver behaves because the driver
can potentially run on a system.
That has very low memory consumption.
And it's still important for the driver,
not to blue screen the system, but for our purposes,
let's just go ahead with the standard test.
And hope for the best.
So here's the standard settings.
Let's continue.
Now, the next question, is which drivers would I like?
To use to apply, these tests on.
So the first option,
is to select unsigned drivers which is not likely to be a very useful option in
general because drivers must be signed on Windows However,
it is possible.
To put the system into test signing, mode So that I can load drivers,
which are not signed.
So maybe I want to try those out currently.
Uh this is In fact, the case of this system,
it's running in test, mode which really means that test,
signing, is off.
But on a typical RT M normal machine.
That doesn't have test signing enabled.
This option doesn't really mean anything.
It's possible.
To try to target very old drivers which is completely useless for
today's Windows This option actually should actually be removed
because it tries to Um Look at drivers from the NT four days which was
only 32-bit obviously doesn't apply.
To Windows 11, which is only 64-bit So this option, is kind of useless.
And only makes some distant sense on a 32 3 bit system.
You can select to check all drivers, that are installed, in the machine.
This is not recommended because there is some overhead
because of the various applications.
And settings, their driver, verifier, is applying.
So you don't want to check all possible drivers, the system will be very slow.
So if you have the case, that you suspect something,
is wrong, but you don't have any lead.
And you don't have any suspicious drivers up front,
you can do a different kind of thing.
Instead of selecting all drivers, you might check,
use a different scheme by selecting,
let's say 15 drivers test the system with that if nothing blue screens,
then test the next 15 drivers.
And So on until you hone in on the problematic driver.
So you should probably not use this option ever.
The most sensible option.
To use is to select, a driver or drivers from a list.
Once we click Next, here we get a list of all the drivers currently.
In the system currently.
Running in the system as you can see these are all the drivers.
It doesn't matter which company or developer wrote that driver,
and one of them should be my fault if it's recognized.
And If it's not, we'll be able to add that manually.
So let's find my faults.
See if it's here.
So my fault.
Is here because it is currently loaded.
But if even if you have a driver, which will be loaded later, you can go ahead.
And use this option.
To add, a cease, file for drivers.
That might not be loaded right now but might load some time later.
In this case, I'm going to Use my fault here.
And check,
that That's the only driver I care about because I suspect it's the culprit.
Of course, we can select, more than one and then we just click finish.
And We have to Restart the system for these things.
To take effect because the driver very far will have to provide certain hooks,
and do things, that are only possible,
to do before the driver actually loads or exactly at load time.
So I'm going to Restart the system.
And We'll see what we get once the system.
Is restarted.
I'm going to pause the recording while I restart the system.
Now, that the system has restarted.
Let's run not my fault.
Again.
You might recall from previous experiments.
That When we use buffer overflow,
we had to click multiple times the _____ button,
even that did not necessarily generate a _____.
But now once we have the previous settings in place,
let's click the _____ button at this point,
we get a blue, win immediately.
Let's wait for the down file and Restart the system.
I'm going to Pause the recording until the system.
Is restarted.
Now, that the system has restarted.
Let's go ahead.
And run the debugger and open the resulting dump.
File Here it goes.
The debugger Here's the dumb fi S analyze dash V as usual.
But now you notice there, is a different.
Well,
it's actually showing not my fault here being the culprit looking
at the call stack you notice that my fault,
is doing something.
That calls a function called very far X,
allocate pull X,
allocate pull is the normal standard function for allocating kernel
memory used by drivers but now its been redirected.
To a very far call and the very far is The one noticing this
is coming from special pull and its actually writing
something beyond the allocated buffer.
And we get a blue screen because of that So drive Ver far is a very useful tool,
not just for checking drivers when developers write kernel drivers,
but also trying to Figure out why a blue screen has happened.
If you have some kind of suspicion of a certain driver or even several drivers,
you can just put them either the veri far microscope,
and it will likely to show you which driver.
Is the problematic one.
And where exactly the problem lies