[Instructor] In this lesson we're going to talk about
step two of the CompTIA troubleshooting methodology.
Now this is step two of six,
and in step two we want to establish a theory
of probable cause and question the obvious.
Also, if necessary, you're going to be conducting external
or internal research based on the symptoms you're observing.
So when we talk about establishing a theory
of probable cause we're trying to guess what we think
the problem is based on all the symptoms
we've observed up to this point.
If we've gotten good answers from our initial questions
from our end users this is going to help us determine
the severity of the problem
such as how many people are being affected
and how bad is it, as well as a rough idea
of what we need to investigate
such as is this a hardware issue?
Is it a software issue?
Is it an operating system or an application issue
or maybe it's a driver issue.
All these are things that we have to figure out
and by doing all that initial questioning back
and identify the problem,
we should now have a lot of data to start building our case
and figure out what is our theory that we want to go with
as far as what we're going to try next to solve things.
Now, when we talk about establishing a theory
of probable cause we have to talk about
what is probable cause.
Well, when we talk about probable cause
we're talking about all of the different possible causes
that may have happened but which one is most likely?
For example, it is possible that aliens came down
and scrambled up the bits and bites on your computer
but it's probably not very likely.
So I don't think that's my probable cause
even though it might be a very unlikely possible cause.
So keep that in mind.
When you think about probable cause,
you really need to think to yourself
what is the most likely thing?
Because there's probably three or four things
that it could be and you're going to want to select
the most possible when first we're going to try that,
figure it out and if it doesn't solve the problem
then we can come back again later
and try number two, number three, number four
until we identify exactly what was wrong.
Remember the idea here is to do it in a systematic method
so that we're not overlooking any possible issues
while still doing things in the most efficient
and effective way possible.
For example, if I had a user who was watching video
on Netflix and all of a sudden it stopped working,
well that can have a lot of different reasons.
It could be their TV is turned off,
maybe they didn't pay their electric bill
It could be their internet service went out.
It could be that Netflix is down, or it could be the fact
that their wireless network that's connecting
between their TV that's watching Netflix
and their network to get to the internet
is no longer transmitting
and that's causing a broken link.
This is the idea.
There are lots of problems, and right now
we need to pick one of 'em that we think is the most likely
and that's the probable cause that we're going to go after.
Again here, I always want to remember to question the obvious.
If you're thinking about something like Netflix
they are a really big company that does a really good job
of keeping their servers up and running
almost all of the time.
So it is probably less likely that Netflix is down
than there being an issue with your system
or your internet connection.
And so you might want to check those things first
before you start blaming Netflix and their servers.
Now, in addition to establishing your theory
and picking your probable cause
we'll also be doing internal or external research
based on the symptoms we see.
For example, when I'm dealing with this Netflix example
one of the easiest things I can do to see
if it's my problem or Netflix's problem,
is to go online to a site like Downdetector
and type in netflix.com.
That website tracks and reports on other users who say
that different websites are up or down.
And so if you think Netflix is down
you can go check Downdetector
and see if other people are having the same issue.
This, again, is going to help us verify
if our probable cause is the real cause
or if we need to figure out a different probable cause.
In addition to that, you're not going to know everything
as a technician, but you should at least be able
to figure out how to research and find answers.
For example, I've been doing this for over 20 years,
and I can tell you I still don't know everything
there is to know about them.
That being said, I can solve almost any problem
you throw at me because I know how to conduct research.
If somebody says there's this issue
or this symptom or this error code
I can look those things up because Google
and other search engines are really your best friend here.
You're going to find a lot of the things that you're going to do
on a daily basis can be answered by Google
and usually it's going to be the first, second,
or third result in Google if you search properly.
So don't be afraid to do research
based on the symptoms you're observing.
Also, you want to look at that machine
and make a physical inspection of it
as you're trying to establish and test your theory.
For example, as you go over to the machine
you're going to look at it and you're going to listen.
Do you hear the fan spinning?
Do you hear a clicking sound
or a grinding sound of the hard disc?
Do you smell something that's burning?
Any of these things are symptoms and clues
to tell you what is wrong with that system.
For example, if you smell a burning smell
it could be that you've damaged your processor
or one of the components on your motherboard.
If you're hearing a clicking or a grinding sound
that tells you there's something wrong
with your hard drive.
If you're using a traditional mechanical hard drive
in that system.
If you hear that there's no fan spinning
that could be a power issue
or it could be a broken fan issue.
All these are things you can figure out
by making that physical inspection.
Another thing to keep in mind
is sometimes when you go to fix the system
the symptom that you originally had is no longer there
and so you may want to try to reproduce the problem.
This happens a lot in large organizations
when you're working for their help desk or support system.
For example, in one organization I worked at,
it usually took them one to two days
to send a technician out to your desk
to repair your computer.
So if you had an issue today, such as a program crashing
you're not just going to sit there for two days and not work.
Instead, you're probably going to reboot your machine,
you're going to try a workaround
and you'll start getting back to work where you can
while you're waiting for somebody to come fix the issue
you're having as the root cause.
During that time, you're doing other things
and there may be other symptoms that come up
that you could then tell the support technician about.
Now, on the other side of that equation,
if you're working as a support technician
and you're coming in to fix somebody's problem
when they put in a ticket a day or two days ago
they've already done other things to that system.
So you're going to want to try to recreate the problem
that they initially had
to see if you could see a error message again
or those other symptoms happen.
Some problems are going to be intermittent
but most problems can be reproduced.
So if you can reproduce it
that's going to be able to give you more information
and help you figure out
if you've got the right probable cause
that you're trying to solve.
Another thing to think about when doing your research is
that you can use research, not just online
but also in the system itself.
Each system has its own system documentation.
It has installation and event logs,
it has diagnostic tools for you to figure out
what is working and what is not working.
And all of those things are part of that internal research
to learn more about the system
and learn what the probable cause is
for that particular outage or problem.
And finally, if somebody else has already worked
on that system, you want to talk to them
and figure out what did they do.
If you're working in a small business
and you're the only technician
then you're probably the only person fixing the machines.
But if you're working for a large organization
there may be 20, 30, a couple of hundred other people
who are doing these tickets
and if somebody else has been working on that system already
and they weren't able to fix it
and they pass that off to you
you now need to figure out what did they already do?
What have they already touched?
Or if this person says,
"You know I've had a lot of problems with this computer.
You're the third technician in four months
who's had to come out and fix it?"
Well, let's go talk to the other technicians as well
and figure out what did they do
What did they think the problem was
and what did they try to do to solve it?
Because you don't want to do the exact same thing
because it's probably not going to fix it
because it didn't fix it the last two or three times
and you're just going to upset your customer
because they feel like you're wasting time
by doing the same thing the other person did
last week or last month.
So keep in mind when it comes to step number two,
your whole goal in step number two is to establish a theory
of probable cause, and you always want to question
the most obvious things first.
If you don't know the answer
always feel free to look it up
using external documentation such as the internet
or internal research such as the system itself,
diagnostic tools and the system's logs.