Back in the day, when any program crashed in Windows, it would ask you if you wanted to send
an "error report" or not, and no one ever knew if it made any kind of difference. These days,
error reporting still happens, but it's all in the background and automatic. Which might lead you to
wonder, what the heck is in those error reports anyway? Well in this video you'll find out,
so you can become a true expert. But don't worry if you don't understand everything, I'll
explain the important stuff in a way everyone can understand. Now first of all, what's the point of
error reports anyway? Well they they are actually critically important to discovering software bugs
and fixing them. To really narrow down the cause of a problem, developers want to know as much as
possible about exactly what the program was doing when it crashed, plus some other info about the
computer, in case it only happens in some versions of Windows for example. As for where the reports
go, there was a question-and-answer post done by a researcher at Microsoft that put it simply. "It
goes into a giant database that then gets mined by some incredibly clever software,
and thousands of bugs get fixed based on those reports." He also said, "3rd party developers
can even sign up to get access to the database so they can fix their bugs, too." Now that post is 10
years old, but I'm sure it more or less works the same today. So they're used not only by Microsoft
to fix potential bugs in the operating system, but also, software development companies can register
their software and get error reports related to their software specifically. So for example, if
they push out an update, and then all of a sudden start getting a ton of reports all from users with
a specific GPU, that will clue them in that maybe something in that update is causing the problem.
But it might also show that it only happens to users who aren't up to date on their graphics
drivers, so they can even tell users the way to fix it is to update those. So they are definitely
helpful. Alright now let's go over what exactly happens when a program crashes, and then go over
what exactly is in an error report, and where you can find them on your own computer. And
again don't worry if some of this just sounds complicated, especially at the beginning,
you definitely don't have to follow everything or remember any of the names of things. So,
the first thing that happens when a program, aka a process crashes, is it calls a function built into
Windows called "WerpReportFault". The name isn't important, but 'Wer' stands for 'Windows Error
Reporting', and since this is the entry point to the error reporting procedure, I figured I'd
mention it. Then it will check to see if Windows' Error Reporting service, called WerSvc is running.
And by the way, a 'service' is just a program or process that only runs in the background,
and has no graphic user interface, it's all behind the scenes. If the service isn't already running,
it will start up. Then the service will communicate with the crashing process,
like "whoa what just happened?" And then it will call some other functions that we can skip over,
and eventually calls the process "WerFault.exe", which is important because this is what does all
the work with the reporting the crash. Ok fortunately at this point it gets easier
to explain in simpler terms. So this 'WerFault' process then collects a bunch of info about the
crash, which we will see later. This includes information about the 'Exception', which is
the thing/scenario that caused the crash. Or in other words, an Exception is something happened
that interrupted the program's normal procedure. And fun fact, if you've ever seen a program spit
out an error saying "Unhandled Exception", it simply means the program ran into something that
isn't normal (the Exception), such as trying to write to a file and not having permission,
and the programmer literally didn't write any code to 'handle' it. So it's an Unhandled
Exception. And quick side note, if instead the programmer anticipates that particular scenario,
they can write an extra bit of code called an "exception handler" to deal with it. So with
our example, if the program can't write to a file, instead of crashing, the handler might
have instructions to simply show a pop-up telling the user it doesn't have permission, and to try
saving it somwhere else. So if you do ever come across an error that says "unhandled exception",
consider reporting that to the developer, especially if it keeps happening, assuming
they have some place to report bugs, because it means they didn't anticipate that problem,
but can probably fix it. ------------------ Before we continue, I want to thank today's sponsor,
Blinkist. Now, I definitely don't get around to reading as much as I want, even though I know
there's plenty of books with good ideas out there. So if you're the same way, that's where Blinkist
comes in. It's an app that takes thousands of the top non-fiction books across 27 different
categories, and creates much shorter text and audio explainers they call "blinks" for each one,
as well as producing "shortcasts" which are blinks for podcasts. Each Blink is around 15 minutes,
but you can even speed that up if you want, and in that time you'll learn the biggest takeaways
and most powerful ideas from the book. A few blinks I've listened to recent are Deep Work,
The Myth of Sisyphus by Albert Camus (a classic), and one that I'd legitimately recommend, not
just because this is sponsored, which is Crucial Conversations. It's a book that I've read before,
so listening to the blinks was a great refresher for me, and will definitely give you the major
concepts discussed in the book, which is basically about how to not blow it when having high stakes
conversations in everyday life, it's super valuable. So if you want to check out Blinkist,
go to Blinkist.com/ ThioJoe to get a one week unlimited free trial to try it out. The trial is
completely free and you can cancel at any time, but just for you all, if you do decide to get a
premium membership, you'll also get 25% off that. So again, go to Blinkist.com/ThioJoe and the same
link is down in the description. And now let's continue. Alright so after the WerFault process
collects some initial information, the next thing it collects from the crash is a so-called 'Memory
Dump', which is basically what data was in the Memory or RAM during the crash, so this includes
functions the program just called, and sometimes the actual values of variables in the program,
which is called a 'heap'. Put simply during a memory dump, the process just says "uhh here just
take everything I was working on, you go figure it out", and dumps all the info into a file. Now,
memory dumps in error reports don't actually contain everything in the memory at the time.
I mean not only would that be a huge security issue because it includes data from every other
program running on the computer, but also every error report would be huge. So instead, the error
report only takes a very small fraction of the info, and only that related to crashed process
itself. There is also other stuff the error report probably contains including loaded modules and
stuff, but we should move on for the sake of time. So now onto where the reports get saved.
And that is in the location C:\ProgramData\.. (which is a hidden folder by the way)..
\Microsoft\Windows\WER. In here there are actually three directories - ReportArchive, ReportQueue,
and Temp, but only the first two matter. New error reports first go into the ReportQueue directory,
and after it gets sent to Microsoft, it gets moved into the ReportArchive folder. If there is no
internet connection, it just stays in ReportQueue folder until it can send it. Now each error
report gets its own folder, so if you look in the ReportArchive, you'll see a bunch of folders, each
one representing a crashed process. In each folder there will also be at least a "Report.wer" file,
which contains all the important information and metadata about the crash. And sometimes there
will also be additional info, such as the memory dump we talked about before, but not always. So
now let's get to the thing you're really wondering about, which is what's inside one of these report
files. You can just open it with notepad and... whoaa! I know what you're thinking, "you gotta
be kidding me, what the heck am I even looking at!?" Well we're not going to over all of this
obviously, just a few of the important ones that I looked up and was actually able to understand
and seemed important, and that are also easy to explain. You can probably figure out what a lot
of these are for just by the name, like the Time, report ID, stuff like that. But one of the big
ones to look at is actually near the bottom, the AppName and AppPath entries so with this example,
I had no idea what "CEPHtmlEngine" was, but here I can see it's used by Premiere Pro, so this
must have been a subprocess while running that. Another one that seemed relevant was "ReportType".
Without getting too technical, it identifies one of 6 'types' of crashes,
such as a 'Non-Critical' error that just happened in the background and the user probably never saw,
or an Application Crash or Hang where the program stopped running or stopped responding, which are
error messages we've probably all seen before. Plus there's a few others you can read here,
but I couldn't really find any more info about these report types. Loaded Modules is also usually
important. A module is basically a subcomponent of a program that does a certain task.
An analogy you can think of is how in a company, there are different departments. In this case,
that module that crashed was "CEPHtmlEngine.exe", which turns out to be for the 'Chromium Embedded
Framework', and basically serves as a mini web browser you can include with and embed inside
programs. So a module can also be something that might be included with all sorts of programs,
so it's kind of part of the program, kind of not. In our analogy with a company, you might consider
this an 'independent contractor', if that makes sense. Anyway the name "loaded modules" should be
self explanatory, but it shows all the modules that were loaded at the time of the crash,
and always with the actual crashed one at the top, from my understanding. This is useful for example,
if all the error reports with the crash have a certain module loaded, so maybe that means
it's interfering. Or on the flip side, maybe it's because it's not loading a module that is
supposed to be loaded. The final one we can talk about are 'Buckets' and 'Bucket ID'.
This seems to be especially important and I'll explain why, though it's a bit abstract
so hopefully if you've made it this far you can bear with me. The term 'bucket', which will make
sense later, is short for 'Fault Bucket', and it's essentially an identification number that's
automatically calculated by Windows based on the specific circumstances of the error. For example,
when calculating it, it takes into account the program the crashed, the version number,
and what location in the actual code that the program crashed, plus other factors. And the
idea is to try and group different crashes based on the actual root cause of the crash, not just
the error itself. So say there is some specific type of error that keeps happening to users,
but maybe not all of them happen at the same time in the program, and they might not even have the
same root cause. Windows will do a bunch of fancy calculations with the available info and generate
a 'bucket ID' for the error where other crashes will also have that same 'bucket ID' if the same
type of circumstances result in the error, and therefore it's probably the exact same cause.
The reason they're called buckets, is it's like you put these crashes into this bucket together
because they're probably the same thing, and then these other crashes into another bucket. So
to better understand, imagine a developer wants to fix a bunch of bugs from a bunch of error reports.
Instead of looking at one crash, and then trying to manually find other crashes he thinks are
related, which might end up being a wild goose chase, he can just look at the crashes with all
the same bucket ID, so it's way easier to find the same root cause in all of them most likely. Plus,
it makes it way easier to figure out how many separate bugs are out there, because
you might have a super common crash that generates a million reports, and not know if it's a million
separate bugs or just one. And going back into the error report file, I do believe that these 'sig'
and 'dynamic sig' values are at least some of the information used in calculating this bucket ID,
but I'm not 100% on all that. So that's my understanding of Bucket IDs at least, but I'm sure
there's way more that goes into it that I'm not qualified to explain. As for the rest of the info
in there, if you know I missed a really important one, definitely leave a comment and let me know.
Otherwise, you all can just look through the file yourself and maybe look up some of the other stuff
yourself, if you can find any info about them. Thanks again to Blinkist for sponsoring this
video, again be sure to go to Blinkist.com/ThioJoe to get an unlimited 7 day free trial and 25% off
a premium membership. If you want to keep watching, I'd recommend checking out my
video about the hidden "super shortcut" feature in Windows called Symlinks, so be sure to check
that out right there. Also consider subscribing and enabling notifications with the bell, I post
videos about once or twice a week. So thanks for watching, and I'll see you in the next one.