You're happily using your computer when this happens. Yes, my friends: the Windows stop error;
more commonly known as the blue screen of death. The good news is a quick Google search
will turn up hundreds of suggested fixes for it... the bad news is that you've probably tried
them all and they probably didn't work. If you want to know how to actually fix this,
you need to know how to troubleshoot it; so it's a good job I made a video to show you!
Welcome back to the Pro Tech Show. This is one of those videos that's going to be useful
whether you work in IT or not. If you use Windows you've probably experienced this at some point.
So what is the blue screen of death? It's basically Windows tapping out. It's Windows' way of saying
"Something has gone horribly wrong and I can't recover from it. I'm bailing". The actual cause
can be almost anything. It can be a bug in Windows itself, or third-party software, failing hardware,
data corruption... drivers are a big culprit. In fact, do you remember Windows Vista? It quickly
gained a reputation for being a crashy, bug-ridden mess; but was it really Vista's fault? Partly, yes;
but actually, a lot of it wasn't. Microsoft accounted for nearly 18 percent of crashes, but
what about the other 82 percent? Well, it turns out NVIDIA drivers accounted for nearly 30 percent
of all crashes in the first year. Quite impressive considering the large majority of Vista PCs didn't
actually have any NVIDIA hardware! Not exactly team green's finest moment, but Vista took the blame.
Because the actual cause of these bluescreens can vary wildly you need to troubleshoot your specific
problem on your specific device. If you try random fixes you found on the internet your chances of
success aren't that good, because you're basically hoping to win the crash lottery. That said,
let's get some low-hanging fruit out of the way. I know a lot of the people who watch this channel
are much more experienced with computers than the average person, and may be more inclined to
tweaking as a result. If you've tweaked anything into a non-standard state: if you've overclocked
your hardware or undervolted it; then before you do anything else return it to stock settings.
You will kick yourself later if you spend hours troubleshooting Windows only to find out it was
your own unstable overclock that caused it; so take that out of the equation right from the
start. You might want to try unplugging any non-essential USB devices as well.
Faulty hardware can cause bluescreens so if you can easily pull a few cables to rule it out,
go for it. Obviously, if you know you did something to cause the bluescreen... undo it. If you installed
something just before it crashed, uninstall it. If you can't do that because Windows crashes before
you get that far, stick around because I'll be showing you what to do about that later.
Another thing that's always worth trying is installing any available software and driver
updates. You might get lucky and find a vendor has already issued a fix.
Do not, I repeat do not attempt to update your BIOS unless you know that is actually the fix. If your
computer crashes part-way through that process you may not be able to recover it without physically
replacing the hardware. I'm going to assume none of those suggestions fixed it for you, though; because
otherwise this video is basically over. I'm also going to make an assumption (for now)
that you can boot into Windows. If your computer is crashing before you get to Windows I will cover
that later in the video as well. The first thing we need to do is gather some information. On the
bluescreen itself there should be a stop code, and it might even tell you what file caused the error.
Make a note of that because it's a clue to the cause of the problem. If you missed it don't
worry - we can still find out what it said. To do that we need to take a look in the event log.
An easy way to get to this is to right-click on your Start menu and select Event Viewer.
From there expand Windows Logs and select System. There's going to be a lot of information in here
but we're looking for a specific entry. The event level will be "Error", the source will be
"BugCheck", and the event ID will be "1001". The time of the event should be just after your computer
started back up. You can filter the log to find it more easily but it can be useful to see all the
events surrounding it. If you can spot where the crash occurred you can have a look at events in
the System and Application logs around the time of the crash to see if they give you any clues.
It is fairly normal to see a number of warnings and errors in here so don't panic, but if you see
something consistently erroring out immediately before a crash you might want to take a look
into that particular message a bit more closely. Whatever application logged it might be the source
your problems. For now, though; back to your bugcheck event. If you read the detail it will say
"The bugcheck was" followed by a bunch of numbers and letters starting with "0x". Take that first set
of numbers and letters before the brackets. That is the hexadecimal error code that matches the error
on the bluescreen. If you pop that into Google you can find out what the bluescreen said. I'll link a
list of possible values in the video description to save you Googling them all, though.
That error code might be enough to point you in the right direction. Most of the time it'll
probably lead you towards a driver issue, which isn't particularly useful because it can still
be almost anything at that point. You might get lucky, though; and have a more specific error.
If it mentions a file system for example, then it's talking about your hard drive.
A file system error could be caused by a storage driver, a failing drive, a failing
storage controller (which for most home users would mean your motherboard), or it could be file system
corruption. If it's a disk you need to back it up and replace it ASAP. If it's file system corruption...
well a lot of the time file system corruption will actually prevent Windows from booting so I'm going
to cover that one later in the video when I talk about what to do if Windows won't boot.
The most likely outcome in my experience, though; is that your error code will lead you towards a
driver problem. The next step therefore is to figure out which driver caused the crash
and the event log probably won't be enough to tell you. For that we're going to need a dump.
A memory dump! Usually this will be created automatically when Windows bluescreens,
but you might need to enable this first then wait for it to crash again. To check if memory dumps are
enabled, right-click on your Start menu and select System. The interface here has changed a bit in
recent updates for Windows but you're looking for the "Advanced system settings" option. This
is probably on the right-hand side or the bottom of the page. If you're running an older version of
Windows you might have already landed straight at this location. If it says "System Properties" in the
title, you're in the right place. On the Advanced tab click the Settings button under Start-up and
Recovery. Under the "Write debugging information" section make sure the drop-down isn't set to "none".
If it is change, it to "Automatic memory dump" and OK your way back to the desktop. With that set
your computer will generate a memory dump the next time it bluescreens. Depending on what option you
selected you might get a large dump file located at C:\Windows\MEMORY.DMP. That will have the most
debugging information. If that file doesn't exist, the other place you can look is in C:\Windows\Minidump
for a smaller dump file that also gets created. OK, we've got our dump. How do we use it?
Analysing a memory dump can get quite technical, but I'm going to show you some simple steps to
get a bit of useful information from it. There are some websites you can upload these to but I don't
recommend that. A memory dump can contain whatever was in your computer's memory, and that could mean
sensitive or personal information. To be safe, do the analysis yourself. If you're a home user
the easiest thing to do is install a tool called WhoCrashed. I'll link it in the video description.
This is free for home use, but if you're doing this for a business you have to pay.
Don't worry, I'll show you another tool that's free for everyone in just a minute. The reason
I'm suggesting this tool is simply because it's really easy to use without any technical knowledge.
Just open it click the Analyze button. It will find your memory dump files, do a quick analysis,
and give you a readable enough summary. If you look at my example here you can see it has found that
IRQ level error code that we saw before ,and it reckons the file myfault.sys caused the problem.
It goes on to tell you that that file belongs to your product called Sysinternals Myfault.
If you're wondering what the heck that is, it's a tool called NotMyFault by Sysinternals that
deliberately crashes your computer by creating an unrecoverable driver fault. Not a piece of software
you'd normally want to use, but perfect if you want to deliberately crash a computer so you can record
a video showing people how to troubleshoot it. Now that WhoCrashed tool is really easy to use,
but it's not free for commercial use. There is a tool from Microsoft you can use for free anywhere,
and it will give you more information as well. That tool is called the Windows Debugger, or WinDbg, or
Win Debug. You may have come across this before and remembered it being a pain to find and use.
You had to find the Windows Software Development Kit, download it, then untick every single box other
than "Debugging tools for Windows" because you only actually wanted that tiny piece of a fairly large
package of tools. Then once you've installed it you had to configure your symbol path, and you ended up
with this archaic looking thing. Don't do that. There's a better way. Open the Microsoft Store
and search for WinDbg. You'll find a modern replacement that's just... better, and still free.
At the time of recording it's still in preview, but don't mess about with the Software Development Kit -
just install this one. For completeness I'll put links to both in the video description.
While you're down there, go on and click that like button, and subscribe if you haven't yet.
When you open WinDbg, remember to run as administrator. The tool itself doesn't actually
need administrator permissions to function, but the location your memory dumps are created in is
only accessible to administrators so this will just make life easier for you. The first nice
feature you'll notice if you're used to the old tool is that it automatically detects a recent crash and
asks if you want to open the dump. Yes I do! If it hadn't detected the dump file automatically you'd
load it by clicking on the File menu and selecting "Open dump file" under "Start debugging". Wait for it
to warm up a bit and when you see this blue text that says "!analyze -v" you're ready
to go. Click on that text and wait for it to do its thing. You'll see a progress bar at the
bottom while it's running (another improvement over the old one). This tool spits out a lot more
technical information the last one I showed, but you can easily enough pull out some of the same details.
Here we have our IRQ level error from before, and if you scroll down we're looking for this bit
where it gives you the module name and the image name. The image name is the file that caused the
crash. We can see the same file name myfault.sys as before. If we click on the underlined module name
it may spit back a bit more information about the product it belongs to. In this case it hasn't given
us much new information, but as long as we know the name of the file we can pop it into Google
and figure out what it is. There we go: it's a Sysinternals tool called NotMyFault.
A bit more work to get the information that with the WhoCrashed tool; but not that difficult if you don't
want to pay for it in a business use case, or you simply don't want to install a third-party tool.
The additional information provided by WinDbg can also be helpful for trickier issues.
Let me cause a different type of crash. This time, running that one through WhoCrashed
points a finger of blame at the NT kernel. That's Windows itself. Although Windows did
crash, it crashed because I did something bad to it, so this isn't actually that helpful.
If I run WinDbg against it; it shows the same faulting image name,
but if I scroll back up and look at the process name I can see what really caused it.
WinDbg doesn't try to give you the answer quite as clearly, but the additional information can be
helpful if you don't get anywhere with WhoCrashed. That said, sometimes WinDbg will output a line
that says "Probably caused by". If you see that in the text that spits out, definitely pay attention
to it. So now we know what driver caused the crash, what's next? Well, it depends what the driver is for.
If it's not actually something you need you might simply uninstall the driver software or
remove the offending device and the problem goes away. Assuming it is something you need you should
check on the manufacturer's website for a newer version. It might be that you've updated Windows
and the driver you had is no longer compatible, but downloading the latest version might fix it. That's
actually quite common. You might need to do a bit of research here. It could be that this driver has
a conflict with something else in your computer. Your best bet is to stuff a few search terms into
Google like "crash" and the name of the driver, to see if anyone else is reporting similar problems...
and hopefully a fix. The final thing you should bear in mind with drivers is that they're usually
written to provide an interface between Windows and a physical hardware component. A driver that
keeps crashing is often a software problem, but it can also indicate a hardware failure.
The software might be crashing because the hardware it's talking to has malfunctioned.
If your graphics driver crashes, for example; it could mean that your graphics card is dying.
Once you get into the realm of physical hardware you can go down a rabbit hole. Your graphics
driver could be crashing because your graphics card malfunctioned, but your graphics card might
have malfunctioned because your power supply is undersized and couldn't supply it with enough
power under load. If it was right on the edge before then simple aging might have pushed it over.
When it gets to troubleshooting hardware you generally end up using a process of elimination
by removing or replacing components one at a time, until you find the problem; but at least the crash
dump will have given you a place to start rather than going in blind and hoping for the best.
Honestly, though; for the ones I've dealt with, going onto the manufacturer's website and
installing the latest version of the driver found in the crash dump fixes the problem more
often than not. Hardware failures definitely happen, but software bugs are more common. But
what if your computer won't actually boot? These tools I've showed you rely on you actually getting
into Windows to run them, right? The first thing you can try is booting into safe mode.
You used to be able to mash F8 during start-up to get there, but that doesn't work on a modern system. After Windows
has repeatedly tried to load and fail, though; it should present you with the option automatically.
You might be able to force this as well by holding the power button to do an instant power-off whilst
it's booting a couple of times; but if you're at the point where Windows won't boot you should
get the option automatically. Here's how it came up for me. From here I'll hit F8 for start-up settings,
and four or five to enable safe mode with or without networking. Safe mode loads Windows with
a minimal set of drivers and services so if something is crashing so badly that Windows can't even start,
this might get you around it and let you continue your troubleshooting. Safe mode without networking
is safer as it doesn't load your network drivers. This can be handy if the network drivers are the
ones causing the crash, but it also means you have no network... so no internet to download updated
drivers. You'll have to do that on another computer and put them on a USB drive. If safe mode lets you
boot up, you've probably got a driver issue or some dodgy software loading automatically at start-up.
If you type "msconfig" into the Start menu you can selectively disable different components from
starting automatically. You can use a trial and error approach to try starting up with different
components enabled until you figure out which one caused the crash. This can take a while I'm afraid.
But what if you're bluescreening before you even get into safe mode? It may just be properly
broken at this point, but a lot of the time this is a symptom of file system corruption.
I told you be getting back to this one, remember? If you can't boot into safe mode then you're going to
need to boot into something to fix this. Go to another computer and use the Windows 10 Media
Creation Tool to create a Windows 10 USB install drive or DVD. Link in the description, of course.
Take this back to your knackered computer and boot from the USB or DVD you created. You may need
to change some settings in your BIOS to do this, but usually there'll be a message that pops up
briefly when you start your computer telling you to press a specific key to get to the boot menu. It
will usually be one of the function keys like F12, or it could be the escape key or the delete key.
Once the Windows setup loads, select your language and click "Repair your computer" over in the bottom-left.
Click "Troubleshoot"... now if I just interrupt my own train of thought for a moment here...
If you know that you changed some software and that caused the bluescreen you can use the "System restore" option
on this page to revert your system settings to before that change. Assuming the necessary option
was enabled before you made the change. Let's continue fixing our file system corruption, though.
Click "Troubleshoot" then "Command Prompt". If Windows is booting fine at this point then you don't need
a special boot drive - you can open a command prompt by typing "cmd" into the Start menu and running as
administrator. The command you need to run file system repairs is chkdsk, spelt "chkdsk",
"C:", assuming windows is on the C drive. Sometimes when you boot from another drive your
drive letters get messed around and Windows might be on something other than C. An easy way to check
is to type "bcdedit" and hit Enter. Have a look under "Windows Boot Loader" and if it says "partition="
something other than "C:" then replace C in these commands with that letter instead.
Just running chkdsk by itself won't fix anything - it will just check for corruption.
To fix it you need to run "chkdsk C: /f". If you've booted from a USB or DVD
this will run now. If you've actually booted Windows it can't run this repair now because
the drive is in use, so it will schedule the repair to run when you next reboot.
If you have a mechanical hard drive rather than an SSD I recommend running "chkdsk C: /r"
instead of "/f". This will run a more extensive repair that will attempt to recover bad sectors.
It will take a lot longer, but I've seen this fix bluescreens that the standard "/f" repair
won't. If the act of running chkdsk causes the computer to crash then I'm afraid the most likely
explanation is that your hard drive is failing. Get any data off it ASAP because it's only a matter of
time before you lose it. A good way to do this is to create a Linux live USB or live CD to boot from
and use it to read the drive from outside of Windows and copy the data somewhere else.
How to do that is outside the scope of this video, but if it's something you'd like to
see then drop me a message in the comments. One final thing you might try here, and I
hesitate to suggest this because if you go on a support forum you will see this suggested as
the fix for almost every problem imaginable. I swear there's some person who just copy-pastes
the same suggestion onto every single post because they've got nothing better to do! From the command
prompt you can try running "sfc /scannow". That will scan for and repair some system files. I have literally
never seen that command fix anything, ever; but it presumably worked for somebody, somewhere, once
that they feel the need to post it as a suggested answer to every single question that has ever
been asked. If you're running this having booted from USB or DVD it's a bit more complicated of
a command that's needed, but the information is in BCDEdit that I showed you before.
The full command you'll need is "sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows"
replace "C" with the partition letter from BCDEdit and "\Windows" with the system root from BCDEdit if they're different.
And with that last act of desperation I'm going to wrap this one up. If you follow these steps it
should help you fix most blue screens of death, but ultimately you may come to a point that needs some
hands-on expertise rather than a YouTube video. If you're still stuck, go get some help. Take it
to a shop or someone you trust. Bluescreens can have some really weird causes, so why don't you
let me know in the comments: what is the weirdest cause of a blue screen of death you've ever seen?
I'm honestly a bit scared of what I might see in the comments now, but come on... surprise me!
If you found this video useful, give it a like and consider subscribing if you haven't already
done so. Also, click on one of these because I know you're not ready to just let me go yet.
I'm going to leave it there for now. Thanks for watching, guys. See you next time!