The most valuable crash question costs nothing: is it one app, or is it everything? The answer halves your suspect list before any tool is opened.
Users report both faults with the same words — it keeps crashing — but they are different diseases with different cures. One application crashing while Windows and every other program stay healthy points inward: at that app, its files, its add-ins, or the one driver it leans on. The whole machine crashing — blue screens, freezes, restarts — points downward at the platform: RAM, power, heat or a core driver. Mixing the two up leads to reinstalling Windows for an app bug, or replacing an app while the RAM quietly rots. This guide teaches the split, and the tests that prove each side.
👆 Example crash scopes. Different blue-screen codes each time is the classic RAM signature — one fault, many masks.
Before any repair, answer three questions by observation:
One app + one user + one file means the file. One app + every user means the app or its one shared driver. Everything + everyone means platform — leave the apps alone and go to the hardware tests.
An app that crashes alone has a short suspect list. Its own update is the classic trigger — crashes that began the day the app updated usually end with its next patch or a clean reinstall. Add-ins and plugins are next: most professional apps can start in a safe or no-add-ins mode, and a crash that vanishes there names the add-in. Then comes the one driver the app leans on: creative and gaming apps lean on the graphics driver, accounting apps on the printer driver (a crashing print dialog is famous for this), audio apps on the audio driver. Update or roll back that single driver before touching anything else. And keep one honest option open: sometimes the app is simply buggy and the crash is a known issue — search the exact error text before rebuilding the machine around it.
When the whole PC crashes, read the blue screens as a set, not one by one. Different stop codes on different days — memory management today, a page fault tomorrow, a driver name the day after — is the signature of bad RAM corrupting whatever happens to pass through it. One repeated identical code leans instead toward one driver or one app path. The proving test is MemTest86 from a bootable USB: run it for several passes, ideally overnight. Any error count above zero is a failed result — then test one stick at a time to find the guilty module. Heat and a weakening power supply sit behind RAM on this list, and the shutdown-pattern guide in this set covers their signatures.
Memory lies about frequency; Windows does not. Reliability Monitor (perfmon /rel) draws every crash as a mark on a calendar, grouped by the program or hardware that failed. A wall of marks under one app name confirms the one-app side without any argument. Marks scattered across many programs plus Windows itself confirm the platform side. The calendar also shows the day it all started — and what installed that day. Print or photograph that timeline before you change anything; after the repair, the same chart is your proof the crashes actually stopped, not just paused.
See the split test applied to real crash cases in the video — one-app faults, RAM faults and the Reliability Monitor timelines that separated them.
▶️ Watch Full VideoAlmost never. A single crashing browser usually means a bad extension, a corrupt browser profile or a graphics-driver clash with hardware acceleration. Test with extensions disabled and acceleration off; if it stabilises, the PC was never the problem.
Variety is the message. One faulty driver repeats its own code; faulty RAM corrupts random data, so the crash wears a different mask each time. Run MemTest86 for several passes — a single error is a fail — and test sticks one at a time.
A freeze is a cousin, not a twin: the system is stuck rather than crashed. Failing drives, RAM and driver hangs top that list. Note whether the mouse still moves and whether the disk light is solid — those details, plus Reliability Monitor, separate the suspects.