About CrashDecoder
This site exists because the standard answer to a Windows crash is worse than no answer at all.
Search almost any stop code and you will find the same five pages: run sfc /scannow, update your drivers, check for malware, run a memory test, reinstall Windows. The advice is not wrong exactly, it is just unranked and unexplained. It treats a graphics driver regression and a failing motherboard as the same problem, and it gives you no way to tell which one you have.
That gap costs real money. People replace working memory because a forum told them to. People reinstall Windows on a machine with a board-level fault, destroying the crash history that would have supported a warranty claim. People accept a passing vendor diagnostic as proof their hardware is fine, when those tests routinely miss intermittent faults by design.
What is different here
Every page is built around the same structure, because that structure is what troubleshooting actually requires:
- What the error means - the mechanism, not a restatement of the error text.
- What actually triggers it - causes ranked by how often they turn out to be responsible, rather than listed alphabetically.
- How to narrow it down - specific tests, with what each result rules in or out.
- Fixes in order of cost - cheapest and most reversible first.
- When to stop - the signals that mean the problem is hardware and further software troubleshooting is wasted effort.
That last section is the one most sites leave out, and it is the one that matters most. Knowing when to stop troubleshooting and start documenting is the difference between a replaced machine and an expensive shrug.
Where the content comes from
Two sources. The first is documented behaviour - what a bugcheck parameter holds, what a WHEA event records, how Timeout Detection and Recovery works. That part is verifiable and is written to be accurate rather than padded.
The second is hands-on diagnostic work on machines that were genuinely failing, including a long-running hardware fault on the author's own system that produced eight distinct failures across three different modes before it was pinned down. Much of the practical guidance here - why stress testing misses idle-state faults, why a passing diagnostic is weak evidence, why crash history matters more than any single crash - comes directly out of that.
What this site will not do
It will not promise that a given fix works. Hardware faults are probabilistic and machines differ. Where something is likely, the page says likely; where something is a guess, it says so.
It will not recommend registry cleaners, driver updater utilities, or optimisation software. None of them help, several make diagnosis harder, and their affiliate programmes are the reason so much crash advice is worthless.
It will not tell you a single stop code identifies a single faulty part. It usually does not. What it gives you is a direction, and the honest job of a page like this is to say which conclusions the evidence supports and which it merely permits.
Corrections
If something here is wrong, incomplete, or has changed with a newer Windows release, please say so via the contact page. Technical accuracy matters more than being right the first time, and pages get updated with a revised date when they change.