Windows Keeps Crashing: Complete Troubleshooting Guide

Windows restarts on its own

An uninvited restart is the most disorienting kind of crash because it hides the evidence. Windows recovers before you can read a screen, so the first job is to make it stop hiding: turn off the option that restarts automatically after a failure. In Settings under Recovery, switch off "Automatically restart" so that the next time it fails you get a blue screen to read instead of a silent reboot.

While you're there, note the pattern. A restart that always follows a specific action points at software or a driver; one that comes with heat (loud fan, warm case) points at power or temperature. Once you've captured a blue screen, jump to Blue Screen of Death and Automatic restart after a crash for the follow-through.

Windows freezes and won't respond

A full freeze — cursor stopped, keyboard dead, no task manager you can summon — is different from a slow app that just hasn't caught up. A single hung program is a software problem you can end; a frozen whole system is usually a driver or a hardware fault that has stalled something Windows depends on. The key question is whether the mouse and keyboard respond at all, because that separates the two.

If the freeze is followed by a reboot, you're very likely looking at a display driver, a GPU, or memory, so head to GPU-related crashes and RAM-related crashes. If it's followed by a blue screen, the stop code is your best clue. A freeze that gets worse when the machine is warm is worth checking against CPU overheating.

Blue Screen of Death (BSOD) troubleshooting

The blue screen is not the problem; it's the alarm. The important information is the stop code (a name like IRQL_NOT_LESS_OR_EQUAL) and, if present, a "What failed" line that often names a driver file. Write that code down before the machine reboots — a photo with your phone is a good habit, because the screen can disappear fast. A single blue screen that never repeats is often nothing to worry about; a recurring one is a lead worth following.

Take the code to Understanding stop codes to get a likely direction, then check what Windows logged in Reliability Monitor. If the code keeps pointing at a .sys file, that's a driver, and driver conflicts is the place to work. If the code is memory- or hardware-flavoured, look at defective memory and drive health.

Black-screen crashes

A crash that ends on a black screen rather than a blue one gives you less to read, so you have to look harder for signs of life. Is the monitor's power light on? Is the PC still running (fans, drive lights) even though nothing is displayed? If the system is clearly alive but showing nothing, the display path — cable, GPU, or graphics driver — is the prime suspect.

Try a different cable or port and, if you can, a different monitor to rule out the display itself. If the black screen appears during a driver update or right after a graphics driver change, Display driver crashes is likely the answer, and a driver rollback is the usual fix. If it's accompanied by heat under load, also check excessive temperatures.

Automatic restart after a crash

Windows has a setting that, by default, restarts the computer after a fatal error so you get back to work quickly. For diagnosing a crash, that setting works against you, because it erases the blue screen before you can read it. Turn it off in Settings → System → Recovery under the "Automatic restart" option, and the next crash will pause long enough for you to see the stop code.

Be aware that a genuine power or hardware fault can look identical to an automatic restart — the machine just cycles. If you disable auto-restart and still see no blue screen at all, that tilts the diagnosis toward power or hardware, so check power supply problems and overheating. The distinction between "Windows chose to restart" and "the machine powered itself off" is one of the most useful clues you can get.

Crashes immediately after startup

A crash in the first minute or two after the desktop appears is a strong signal, because so little is running yet. The usual culprits are a startup program that loads and destabilises the system, a display or chipset driver that misbehaves at logon, or — less often — a system component that fails every boot. The fact that it's repeatable and early is actually good news: repeatable crashes are far easier to pin down than random ones.

The cleanest way to test is a clean boot, which starts Windows with the minimum of third-party software. If the crash disappears in a clean boot, you've proven a startup item or service is responsible, and you can re-enable things in groups to find it. If it crashes even in a clean boot, the cause is deeper — a driver or system file — so move to SFC and display driver.

Crashes during shutdown

Crashing on the way out is rarer than crashing during use, and it often points at a specific kind of fault: a driver that fails to hand the hardware off cleanly, a program that refuses to release a resource, or a power-management bug. If the machine hangs at the "Shutting down" screen and then powers off or restarts, a driver stuck in a power state is a very common cause.

Start by noticing whether it's one particular program that's open each time — close or uninstall that and test. If it's consistent regardless of what's open, suspect a driver, particularly the display or chipset driver, and update or roll it back. A crash that only happens on shutdown and never during use is less urgent than a random one, but it's still worth resolving, because it can occasionally point at the same underlying driver problem that later causes a full crash. See driver conflicts.

Crashes after waking from sleep

If your PC is fine while you use it but dies the moment you wake it from sleep, the problem is almost certainly in how a device returns from a low-power state. Windows asks each component to come back to full operation, and a driver that doesn't handle that transition well will crash the system on resume. A blue screen that appears on wake with a power-state stop code is the classic signature of exactly this.

The practical fixes are usually a driver update or a power setting. Update the display, network, and chipset drivers first, since those are the ones that most often misbehave on wake. You can also tell Windows to stop using aggressive power saving for a specific device — for example, unchecking "Allow the computer to turn off this device to save power" for a network adapter in Device Manager. If it's a laptop, the pattern may be tied to the lid or a fast-startup feature; trying shutdown-then-start instead of sleep will confirm whether sleep is the trigger. See driver conflicts and stop codes.

Random crashes with no obvious pattern

Random, unprompted crashes are the hardest kind, because there's no action to reproduce and no program to blame on the spot. When software is the cause, it tends to be something that runs at odd intervals — a scheduled task, a background sync, or an update — so "no pattern" from the user's view can still have a pattern in the system's logs. That's why the first move with random crashes is to gather evidence from Reliability Monitor and Event Viewer rather than guess.

When the logs don't point at a specific program or driver, the balance of probability shifts toward hardware, and memory is the usual suspect: a marginal stick of RAM can cause exactly this kind of intermittent, unrepeatable crash. Run the memory diagnostic covered in defective memory, and check drive health while you're at it. If the crashes cluster when the machine is warm or loaded, also work through temperatures. Random crashes are the main reason to take the hardware path seriously.

Telling a Windows crash from an application crash

A surprising number of "my PC crashed" reports are really one program crashing, not the operating system. The difference matters, because a hung app is fixed by ending that process and, if needed, repairing that one program — not by running system repairs or suspecting your hardware. The tell is scope: if everything else still works and only one window is frozen or gone, that's an application fault. If the whole desktop, the taskbar, and the keyboard are affected, that's a system crash.

Windows usually shows you which it was. An app crash typically produces a "This program has stopped working" dialog or a quiet "Not Responding" tag, while a system crash is a blue screen, a freeze, or a restart. When in doubt, open Task Manager during the next incident: if you can open Task Manager and end the stuck process, it was an app. If you can't, it was the system, and the rest of this guide applies. See Event Viewer for how to confirm which it was afterward.

Windows crashes during boot

A crash before you reach the desktop narrows the field, because almost no user software is running yet. That points at the core: a driver that loads at boot (display, storage, chipset), a corrupted system component, a failing disk, or a recent update that broke the boot process. If you get a blue screen with a code like an inaccessible boot device, the storage driver or the drive itself is usually involved.

If you can't reach the desktop at all, work from the Windows Recovery Environment, covered in WinRE. Try Startup Repair first, then a System Restore to a point before things broke. Because a boot crash is often a recent update, removing a problematic update is frequently the actual fix. If the drive is the suspect, drive health is the place to confirm it.

Windows crashes immediately after login

Getting to the desktop and then dying within seconds is a useful pattern, because it means the base system boots but something that loads with your user session is the trigger. That's typically a startup program, a shell extension, a sync client, or a display driver that fails once the graphical session starts. It's repeatable, which makes it tractable.

The fastest test is to sign in and see how long you have. If you can open Task Manager, end the most likely suspect. If you can't, boot into Safe Mode (which loads the minimum of startup items and drivers) and see whether it stays up. If Safe Mode is stable, a clean boot lets you re-enable startup items one group at a time to isolate the culprit. If it crashes even in Safe Mode, look at display driver and system files.

Troubleshooting with Safe Mode

Safe Mode is one of the most useful tools in this whole guide, because it strips Windows down to the essentials: core drivers, no startup programs, no most third-party services. That makes it a diagnostic as much as a mode. If your PC is stable in Safe Mode but crashes in normal mode, you have just proven the problem is third-party software or a non-essential driver, and that's a huge step forward.

You can usually reach it from the Recovery options (hold Shift while choosing Restart, or from Settings → Recovery), and there's also a "Safe Mode with Networking" variant if you need to download a driver. Use it to uninstall a bad program, roll back a driver, or disable a startup item — then reboot normally and test. The key discipline is to change one thing, leave Safe Mode, and see if the crash is gone before you change the next. See clean boot for the non-boot version of the same idea.

Using the Windows Recovery Environment (WinRE)

When Windows won't start normally, the Recovery Environment is where the real repairs live. It's the blue screen of options that offers Startup Repair, System Restore, Uninstall Updates, Command Prompt, and the Reset options. Getting there reliably matters: if repeated failed starts trigger it automatically, great; otherwise you can force it by holding Shift and choosing Restart, or by powering the machine off and on a few times to trigger automatic repair.

Work the options in order of least disruptive first. Startup Repair and System Restore try to fix things while keeping your files and most of your software. Uninstalling the most recent update is a targeted move if a Windows Update is the cause. Command Prompt gives you access to repair tools like the system file checkers from a repair context. Reset is the heavier option and is covered separately in When to use Windows Reset. If you can't get to WinRE at all, that's usually a disk problem worth checking in drive health.

Startup Repair

Startup Repair is the automatic, low-effort first attempt from within the Recovery Environment. It scans for things that prevent Windows from starting — a missing or damaged boot file, a broken system component — and tries to fix them without you specifying what. It's worth trying because it's non-destructive and it sometimes resolves exactly the kind of problem a bad update or a failed install creates.

The limitation to keep in mind is that it's a generalist: it handles common boot failures well but won't fix a bad driver, a piece of conflicting software, or a failing disk. So if Startup Repair reports it couldn't fix the problem — which is common — don't treat that as failure, treat it as information. Move to the more targeted options: System Restore to roll back to a known-good state, or uninstall a recent update if that's the likely trigger. If even these don't help and you suspect the disk, check drive health.

System Restore after repeated crashes

System Restore is the tool that reaches back in time to a point when Windows was working, undoing system changes — driver installs, Windows updates, some software changes — without touching your personal files. If you can pin down roughly when the crashing started and there's a restore point just before it, this is often the single most effective fix available, because it reverses whatever change caused the instability.

It's available both from within Windows (search "Create a restore point" → System Protection → System Restore) and from the Recovery Environment when you can't boot. The practical caveat is that restore points only exist if the feature was on, and they don't go back indefinitely, so an old crash may predate every available point. Also understand what it does and doesn't revert: it won't undo a bad piece of RAM or a failing disk, so if the root cause is hardware, restoring just buys time. See recovery strategy for when to set a restore point before you do anything risky.

Diagnosing a boot loop

A boot loop — Windows starts, fails, restarts, starts, fails, again — is a crash that has become a loop, and it's usually the result of a change that breaks startup just enough to reboot but not enough to be obvious. The classic causes are a bad Windows update, a driver that fails during the boot sequence, or a system component that gets further along each attempt and then trips the same fault.

Your first job is to break the loop long enough to act. Force the Recovery Environment (by interrupting startup a couple of times or holding Shift on Restart) and work the options in this order: uninstall the most recent update, then System Restore to a point before the loop began, then Startup Repair. If it was a driver, driver conflicts and a rollback from Safe Mode may be the answer. If none of these break the loop and the drive is old, a failing disk can manifest exactly like this, so drive health is worth confirming before you reach for a reset.

Troubleshooting a recent Windows update

Timing is the cheapest diagnostic you have, and "it started right after a Windows Update" is one of the strongest signals you can get. Updates can introduce a driver, change a system component, or enable a feature that destabilises a particular machine, and the crashes that follow are often directly caused by that change rather than by anything you did.

Check the update history (Settings → Windows Update → Update history) to confirm what landed and when, then use the most targeted fix first. In the Recovery Environment you can uninstall the latest quality or feature update, which is cleaner than a full restore when a specific update is the trigger. If the update also dropped a driver, you may need to roll that driver back too — see display driver. Don't just disable Windows Update to "fix" this; that leaves you unpatched. The goal is to remove or work around the specific change while staying current. See also Reliability Monitor, which timestamps updates against your crash history.

Removing problematic startup applications

Startup applications are the most common software cause of a crash shortly after login, because they all launch at once and any one of them can be unstable. You don't have to uninstall them to stop them starting — Task Manager's Startup apps tab lets you set an item to Disabled, which simply stops it launching at sign-in while leaving the program fully usable on demand. That's a low-risk, fully reversible change, which makes it a good early test.

The method is to disable the less-essential items (game launchers, chat apps, media players, vendor utilities) and see whether the early crash stops. Change a batch, reboot, test; if it's stable, you've found the group, and you can re-enable them one at a time to name the specific app. If a particular program is the culprit, update it, repair it, or uninstall it. This is the everyday version of the same isolation logic as clean boot, and it's often all a "crashes after login" problem needs.

Clean boot troubleshooting

A clean boot starts Windows with only the bare minimum of Microsoft services and no third-party startup items. It's the standard way to answer the question "is this my software or the system?" because if the crash disappears in a clean boot, a third-party program or service is involved, and if it persists, the cause is deeper — a driver or a system component.

On Windows you set it up with the System Configuration tool: disable all non-Microsoft services, disable all startup items, reboot, and test. If the crash is gone, you re-enable services and startup items in halves, rebooting and testing between each, until you've isolated the offender. The two rules that keep this safe are to change one group at a time and to remember how to reverse it — you can flip everything back to normal in the same tool. Don't disable your security software or core Windows services as part of this. It's a powerful but optional step; many crash problems are resolved well before you need it. See Safe Mode for the boot-level equivalent.

Display driver crashes

The display driver is one of the most frequent crash culprits, and it has a distinctive signature: the screen flickers or goes black, sometimes the whole system hangs, and Windows recovers — often logging a "display driver stopped responding and has recovered" event. That automatic recovery is Windows resetting a graphics driver that hung, and while it's designed to be non-fatal, repeated instances (or ones that escalate to a full blue screen) mean the driver or the GPU is the problem.

The safe, standard fix is to update the graphics driver from the manufacturer (NVIDIA, AMD, or Intel) or from Windows Update, and if a fresh install makes it worse, to roll the driver back to the previous version from Device Manager. A clean driver install (removing the old one first) can resolve a corrupt install. If the crashes only happen under heavy graphics load, the driver may be a red herring for an underlying heat or power issue, so check temperatures and GPU-related crashes before you blame the driver alone.

GPU-related system crashes

Crashes that cluster around gaming, video editing, or anything that pushes the graphics card hard are a strong pointer at the GPU or what's feeding it. The card may be running too hot, drawing more power than the supply can comfortably deliver, or running a driver that can't handle the load. A freeze or blue screen that only appears in games, and never on the desktop, is the textbook pattern.

Work it in this order: first the driver (update or clean-install, from display driver), then temperature (is the card hitting high temps under load — see temperatures), then power (does it crash even at lower settings, and is the PSU adequate — see power supply). A useful test is to lower the graphics settings or cap the frame rate and see if the crashes stop; if they do, it's a heat or power limit rather than a simple driver bug. If the GPU is old and consistently failing under load, that's a hardware decision, not a settings one. See stress testing for how to confirm.

CPU overheating

When the processor gets too hot it slows itself down to stay safe (throttling), and if it gets hot enough it can force a shutdown or a crash to avoid damage. So overheating can look like slowness, a loud fan, a restart under load, or a blue screen — it's not always dramatic. The pattern to watch for is that the problem appears after the machine has been running a while, or specifically under load, and that the fan is working hard.

Check actual temperatures with a basic monitoring tool while you reproduce the load; sustained readings near the top of the normal range point at cooling. The safe, common fixes are clearing dust from the vents and heatsink, making sure the fan is actually spinning, and — on an older machine — recognising that the thermal paste has likely dried out. That last one, and a physically failing fan, are jobs for a proper clean or a service, not something to keep pushing. Laptops are especially sensitive here. See excessive temperatures for the broader picture and this article for the CPU-specific path.

Excessive system temperatures

Heat is a cross-cutting cause: it can throttle the CPU, stress the GPU, and in extreme cases trigger a protective shutdown that looks exactly like a crash. That's why, when a crash is tied to load or to time (the machine runs fine for a bit, then dies), temperature is worth checking even if the CPU isn't the obvious suspect. A hot room, a blocked vent, a dust-clogged heatsink, or a dried-out fan all raise every component's temperature at once.

The approach is to measure, not guess. Run a lightweight temperature monitor and watch the CPU and GPU while you do the thing that normally triggers the crash. If one of them is climbing into a high range and the crash follows, cooling is your problem. Clear the dust, ensure the fans spin, keep the vents unobstructed, and use the machine on a hard flat surface if it's a laptop. Where the fix is thermal paste or a failing fan, that's a service-level job. The thresholds vary a lot by hardware, so treat any specific number as a guide rather than a limit. See CPU overheating and GPU crashes.

RAM-related crashes

Memory is a deceptively common cause of crashes, and its signature is that it looks random. A faulty section of RAM can corrupt data that Windows or a driver is relying on, producing a blue screen that seems to have no reproducible trigger, a freeze, or an app that crashes in a way that doesn't make sense. If your crashes are intermittent, come with memory-flavoured stop codes, and no software change fixes them, RAM should be on the list.

The way to find out is a memory test, which is covered properly in defective memory. The short version: run the built-in Windows Memory Diagnostic (or a longer third-party test for a more thorough pass) and see if errors are reported. If you have more than one stick, a useful physical test is to try them one at a time — if the crashes follow a particular stick, you've found the faulty module. Failing RAM is a replace-a-part situation, and it's one of the cheaper hardware fixes. See also random crashes, where memory is the leading suspect.

Diagnosing defective memory

Memory problems are frustrating to diagnose precisely because they're intermittent — the same stick can pass a quick test one day and fail the next. The built-in Windows Memory Diagnostic is a reasonable starting point: it reboots the machine and runs a pass over the RAM, reporting any errors it finds. A pass doesn't fully prove the memory is good (it's relatively quick), but a fail is a strong signal.

For a more definitive answer, a longer, repeatable memory test is the standard. The practical isolation method is to test one module at a time: if you have two sticks, pull one and test, then swap and test the other. If errors only appear with a specific stick installed, that module is the culprit and should be replaced. This physical isolation is often more conclusive than any single test run, because it ties the failure to a physical component. If the memory is genuinely bad, replacement is straightforward and inexpensive. This is the article to come back to for any random crash that software fixes won't touch.

Storage drive errors

Because Windows and everything on it live on the storage drive, problems there can surface as crashes, freezes, slow file access, or a system that can't finish booting. A drive with file-system errors or bad sectors can corrupt the data Windows is trying to read and trigger a crash, especially one that points at disk access. The more subtle the drive is failing, the more the crashes can look random.

The safe first step is a file-system check, which finds and fixes logical errors. The standard tool is chkdsk, and it's covered in checking the file system — note that on the boot drive it runs at the next restart. Beyond logical errors, the deeper question is whether the drive is physically degrading, which is a health matter rather than a repairable one; that's drive health. The one rule that matters above all others: if you suspect the drive, back up your important files before you run any repair, because a failing drive is exactly when data is at risk.

SSD and HDD health problems

Most modern drives report their own health through SMART (Self-Monitoring, Analysis and Reporting Technology), a set of internal sensors that track things like the number of repaired sectors and read errors. Checking these is the difference between "the drive is slow" and "the drive is failing." A drive that's degrading can cause random crashes and stutters long before it fails completely, and SMART data is how you find out early.

You can read SMART health with the drive's own utility or reputable disk-health software; a drive reporting reallocated sectors on the rise or a "caution"/"failing" status is a warning to act. The critical response is to back up your data immediately — not after a repair, before it — and to plan on replacement. A failing drive is not something to repeatedly try to repair; it's something to replace, ideally with a healthy drive (or an SSD if you don't have one). This is the article to reference whenever a random crash resists every software fix, because a dying disk is the classic "invisible" cause.

Motherboard and firmware issues

The motherboard is where all the components talk to each other, so a fault there tends to be broad and hard to pin to a single symptom — random crashes, components not being detected, or instability that seems to affect several things at once. It's lower on the list than drivers, memory, and heat, because those are far more common, but when a machine has passed all the software and obvious-hardware checks and still crashes unpredictably, the board (or its firmware) is a legitimate suspect.

The one motherboard-level change that's safe and sometimes helpful is a firmware (BIOS/UEFI) update from the manufacturer, which can fix stability and compatibility bugs — but only from the official source, and only if the vendor indicates an update is warranted, because a botched firmware flash is a serious risk. Beyond that, a failing board is a replace-the-component or professional-repair situation, not a home fix. If you've reached this article, you've probably done the diagnostics in memory stability and stress testing already, and it's worth confirming with a technician before assuming the board is dead.

USB devices causing instability

It's an under-appreciated cause, but a faulty or poorly powered USB device can destabilise a system — a failing external drive, a dodgy hub, or a peripheral with a bad cable can trigger crashes, especially ones that come with a device being connected. The clue is correlation: does the crash happen when a particular device is plugged in, or after you use it?

Test by elimination. Unplug everything non-essential (external drives, hubs, printers, capture devices) and see whether the crashes stop; if they do, reconnect devices one at a time to find the offender. Try the device in a different port and, for anything with a cable, a different cable. If a specific device consistently causes instability, it's the device, not your PC — and the fix is to stop using that unit or that port. This is a quick, satisfying check when the crashes seem to appear out of nowhere but actually track a plugged-in peripheral. See driver conflicts, since a USB device can also bring a bad driver with it.

Network adapter driver problems

Network adapters are a common and often-overlooked crash source, particularly in connection with sleep and power management. A network driver that doesn't handle the device being powered down and back up cleanly can crash the system on wake, and a blue screen that appears when you resume from sleep frequently has a power-state stop code that points at exactly this. Wi-Fi and Ethernet adapters are both implicated.

The standard fixes are a driver update (from the adapter maker or Windows Update) and a power setting. In Device Manager, on the network adapter's Power Management tab, you can uncheck "Allow the computer to turn off this device to save power," which removes the power-state transition that's triggering the crash. If the crashes are tied to waking from sleep, this is one of the highest-yield checks. If a driver update is what introduced the problem, rolling the driver back is the move. See crashes after sleep for the sleep-specific angle and stop codes to confirm a power-state code.

Audio driver crashes

Audio drivers are a less common but real crash cause, and the pattern is usually specific: the system hangs or crashes when audio is playing, when a particular app starts sound, or after a sound-related setting changes. Because audio runs continuously in the background, a faulty audio driver can cause crashes that seem to come from nowhere even when you're not deliberately doing anything with sound.

Start with the driver itself: update it, or do a clean reinstall, from the audio hardware's manufacturer or Windows Update. If a specific audio application triggers the crash, test with that app closed to confirm the link, and check whether it uses its own audio engine or overlays that can conflict. A useful diagnostic is to see whether the crash still happens with a basic, generic audio driver rather than the vendor's feature-rich one — if it stops, the vendor driver is the culprit. This is a smaller corner of crash troubleshooting, so if audio isn't in your crash pattern, you can likely skip it. See driver conflicts for the general approach.

Chipset driver problems

The chipset drivers are the low-level software that lets Windows manage the motherboard's built-in components — USB controllers, the storage controller, power management, and more. Because they sit underneath so many devices, a bad or outdated chipset driver can cause instability that's hard to attribute to one thing: random crashes, devices misbehaving, or power-management faults. They're not the first driver people think to update, which is exactly why they're a common overlooked cause.

The right source for chipset drivers is the motherboard or PC manufacturer — not a generic driver utility. Installing the vendor's current chipset package can resolve a surprising number of stability issues, particularly on a freshly assembled system or after a major Windows update that changed expectations. As with all drivers, if an update makes things worse, a rollback is available. This is a "make sure it's current" check rather than a deep investigation, and it pairs naturally with motherboard and firmware and a general pass over your other drivers. See recent updates, since a new Windows update can sometimes outdate the effective chipset support.

BIOS/UEFI firmware considerations

Firmware (BIOS/UEFI) is the lowest layer of software on the machine, and it handles boot, hardware initialisation, and some power and thermal behaviour. An outdated or buggy firmware version can be behind crashes and instability that no Windows-level fix touches, and occasionally a firmware update from the manufacturer is exactly what resolves a stubborn stability problem — particularly around memory compatibility or power management.

The caution here is real: updating firmware is one of the few "risky" steps in this guide, because an interruption during the flash (a power loss, a forced shutdown) can, in the worst case, brick the board. So the rules are to only update from the official manufacturer source, to follow their instructions exactly, to make sure power is stable (a desktop, or a laptop on AC power), and to have a good reason to do it — a known stability fix the vendor has documented — rather than updating just in case. If you're unsure whether your firmware is implicated, that's a good moment to bring in a technician. See motherboard issues for context.

Power supply problems and random shutdowns

A failing or underpowered supply is one of the causes that most closely mimics a "crash" while actually being the machine losing power. The signature is a shutdown or restart with no blue screen at all — the system just goes off, often under load, as if someone cut the power. If you've disabled the automatic-restart feature (see auto-restart) and still see no blue screen, power is a strong suspect, because a genuine software crash would have shown one.

Power problems are the hardest to diagnose at home, because you can't easily measure a supply's output without proper tools. The practical checks are indirect: does the crash happen specifically under heavy load (a game, a render)? Does it happen with a different, known-good power cable or wall outlet? On a desktop, if you have access to a spare compatible PSU, swapping it is the definitive test — if the crashes stop with a different supply, you've found it. A marginal PSU is a replace-the-part decision, and it's worth a technician's assessment before you keep loading a machine that's dropping power. See stress testing, where a crash only under sustained load is a key clue.

Running System File Checker (SFC)

System File Checker scans the protected files of Windows and replaces any that are damaged with known-good copies. It's a repair command, but a gentle one: it doesn't touch your personal files or your settings, and it's safe to run whenever you suspect system-file corruption. It's one of the standard early steps for a crashing PC precisely because it's low-risk and it fixes a real class of problems.

sfc /scannow

Run it from an elevated (Administrator) Command Prompt or PowerShell. Let it finish — it can take a while — and read the result. It will tell you whether it found and repaired corrupt files, found problems it couldn't fix, or found nothing. "Repaired" is a good sign and may have fixed your crash; "couldn't fix some" means the underlying source (often the component store) needs attention, which is where DISM comes in. "Found nothing" doesn't rule out your problem — it just means the protected system files are intact, so keep going. See corrupted system files for how to interpret the results.

Using DISM to repair Windows

DISM (Deployment Image Servicing and Management) is the tool that repairs the deeper layer — the Windows component store that SFC draws replacement files from. The logic is: if SFC can't fix a corrupt file, it's often because the copy it would restore from is itself damaged, and DISM repairs that source. That's why the usual order is DISM first, then SFC.

DISM /Online /Cleanup-Image /RestoreHealth

Run it from an elevated Command Prompt. It uses Windows Update (or a specified source) to get healthy files, so it needs an internet connection in the default case, and it can take a good while — let it reach 100% before you judge it. A successful run means the component store is repaired, after which re-running SFC can often fix the files that were previously stuck. If DISM itself reports it can't repair the store, that's a signal the corruption is significant, and you may be heading toward a more involved repair or the recovery options in Recovery options. See component store for what this actually is.

Repairing a corrupted component store

The component store (the WinSxS folder, behind the scenes) is where Windows keeps its library of system files and features. It's not something you browse or edit — you repair it with the tools. When it gets corrupted, the symptoms ripple outward: updates fail, features misbehave, and SFC can't repair files because its source is bad. A corrupted store is a step up from an ordinary damaged system file in both cause and how you fix it.

The repair path is DISM's RestoreHealth, which is specifically built to bring the store back to a healthy state, followed by SFC to clean up the individual files. If DISM can't repair it — which can happen when the corruption is severe or the source it needs isn't available — the honest options narrow: an in-place repair install of Windows (which refreshes the system while keeping your files) or, as a last resort, a clean install. That's a decision for the recovery section, but the point here is to recognise when store corruption has moved from "repairable with a command" to "needs a bigger intervention." See recovery strategy before you commit to the larger steps.

Checking the Windows file system

This is about the file system on your drive (NTFS, typically) rather than the system files themselves. A file system with logical errors can misread data, corrupt what it's writing, and trigger crashes or boot failures. The tool for it is chkdsk, which checks the file system's structure and can fix inconsistencies. It's a repair command that works directly on the disk, which is why the caution applies.

chkdsk C: /f

Because the boot drive is in use, Windows will schedule this to run at the next restart, which is normal — confirm the prompt and reboot. It can take a while, and you should not interrupt it. The important prerequisite: back up your important data before running it, because working directly on a disk that might be failing is exactly when you want a safety copy. A clean result means the file system is logically sound; a long list of fixed errors means it was a real problem and is worth watching. This complements storage errors and drive health — the file-system check addresses logical errors, while drive health addresses the physical disk.

Diagnosing corrupted system files

System files can get corrupted by an interrupted update, a power loss, failing storage, or software that overwrites them. The symptoms are often broad and confusing — random crashes, features that error out, updates that fail — because a damaged core file can break lots of things at once. The point of "diagnosing" here is really running the checks that both detect and, in most cases, fix the corruption, rather than hunting for a specific bad file by hand (which you should never do).

The diagnostic sequence is the one in DISM then SFC: DISM repairs the source, SFC repairs the files. Read what they report. If SFC says it repaired files and your crashes stop, that was it. If it says it found corruption it couldn't fix, the component store is the likely source, and a second DISM pass or a repair install may be needed. One thing to be clear about: these tools repair, they don't just report, so a "diagnosis" here is also a treatment. If the corruption keeps coming back, that points at a deeper cause — often failing storage — so pair this with drive health.

Understanding Windows Error Reporting

Windows Error Reporting (WER) is the system's mechanism for logging and, optionally, sending information about problems — both application crashes and system crashes. For troubleshooting, its value is that it records what failed and when, and it's where some of the details about a crash live. You can view its settings and history through the WER control panel applet.

In practice, for a crashing PC, WER is most useful as one of several sources of the same information you can get elsewhere. The crash details it collects often overlap with what Event Viewer shows and what's in the dump files. The one thing worth knowing is that WER can be configured to collect less (or more) and to stop sending data online if you prefer — a privacy setting rather than a troubleshooting one. If you're chasing a specific app crash, WER's history can name the faulting module, which points you at the offending program or driver. It's a supporting tool here rather than a primary one; the primary reading tools are Reliability Monitor and Event Viewer.

Reading Reliability Monitor

Reliability Monitor is one of the most underused tools in Windows and probably the best first stop for a crashing PC. It shows a day-by-day reliability rating with the specific failures plotted — system crashes, application errors, and, importantly, Windows Update activity on the same timeline. That last part is gold, because it lets you line up a crash with an update or an install that happened just before it.

You get to it by searching "Reliability Monitor" or via the Action Center. Look at the days where the rating dips: each dip is a click that opens the events of that day. Read the crash entries — they often name a faulting component or driver, and they sit right next to any updates that landed. If every crash clusters after an update day, that's a very strong signal to work the update. If the crashes are evenly scattered with nothing around them, that tilts you toward hardware, and you'd move to memory and drive health. It's the bridge between "it crashes" and "here's what was happening when it did," which is why it's near the top of this category. See finding crash events for the deeper Event Viewer view.

Using Event Viewer

Event Viewer is the detailed logbook behind Reliability Monitor, and it's where you go when you need more than the summary. Under Windows Logs → System you'll find the raw events, including the crash (BugCheck) events, with identifiers and, for some, the stop code and the faulting driver. It's denser than Reliability Monitor, but it has more of the specific detail.

The practical way to use it for a crash is to filter for what matters rather than wading through everything. In the System log, look for events with a red error icon around the time of your crashes, and specifically for the "BugCheck" source, which records blue screens. The event details can include the stop code and a parameter that names a driver file — that filename is a direct lead to a driver problem. If Event Viewer is overwhelming, remember that Reliability Monitor is the friendlier version of the same data. For the specific crash events and how to read them, see finding crash events, and for what to do with a dump file it references, see dump files.

Finding useful crash events

The goal here is to turn "it crashes" into a specific, logged event you can act on. The most useful events for a crash are the BugCheck (blue screen) entries in the System log, the Kernel-Power event that records an unexpected shutdown, and any application-error entries if you suspect a specific program. Learning to spot and read these three saves a lot of guessing, because each points in a different direction.

A BugCheck event is the most informative: it corresponds to a blue screen and often carries the stop code and a faulting driver, so it takes you straight toward understanding the code or a driver. A Kernel-Power event with no preceding BugCheck is telling — it means the system powered off without a blue screen, which is the signature of a power or hardware issue (see power supply) rather than a software crash. Application-error entries name a specific program and a faulting module, which is how you confirm an app crash versus a system one. Read the events around your crash times, and the pattern of which events appear is itself the diagnosis. This is the "read the evidence" step that the whole guide is built on.

Understanding Windows dump files

When Windows hits a fatal error, it writes a memory dump — a snapshot of what was in memory at the moment of the crash. These dump files (minidumps are the small per-crash ones) are the raw material that crash-analyzers use to pinpoint the faulting component. For most users they're not something you read by hand, but knowing they exist and where they go is useful, because they're what a technician or an analysis tool works from.

Minidumps are typically stored in C:\Windows\Minidump. You don't need to do much with them directly for everyday troubleshooting — the stop code and the Event Viewer entries (see crash events) usually get you 90% of the way. But if you've got a recurring, hard-to-pin crash, the minidumps are the next level of detail, and they can be analysed with a disassembler tool to identify the exact driver or component at fault. If the analysis consistently names a driver, that's your answer; if it points at kernel or system code, the cause is deeper. This is the article to reference when the stop code alone hasn't been enough, and it's a natural handoff point to a technician if you don't want to analyse them yourself.

Recently installed software causing crashes

Timing is everything here. If the crashing started shortly after you installed a program, that program is the leading suspect — not because all new software is bad, but because it's the one thing that changed. New software can crash the system by installing a bad driver, adding a conflicting background service, or hooking into the shell or the graphics stack in an unstable way.

The fix path is straightforward: identify what you installed around when the problem began (the install date in Settings → Apps, or your own memory), and uninstall it. If the crashes stop, you've found it, and you can try an older or updated version of that program if you need it. If you installed several things at once, uninstall them and, if you still want them, add them back one at a time while testing. This is the software side of the same "what changed recently" logic in recent updates — the principle is identical, the thing that changed is just an app instead of an update. See crashes after installing hardware or software for the combined case.

Antivirus and security software conflicts

Security software sits deep in the system, inspecting files and processes as they run, which makes it powerful and also makes it a frequent source of instability when two such tools clash or a single one misbehaves. Running more than one real-time antivirus is a classic mistake: two programs both trying to intercept the same operations can deadlock, slow things to a crawl, or crash the system. A buggy update to a security product can also trigger crashes that look unrelated to it.

The first check is simple: how many real-time security products are installed? There should be one (Windows Defender is built in and sufficient for many people). If you've layered a third-party antivirus on top of something else, uninstall the extras. If a single product's update coincided with your crashes, updating it fully or rolling it back may help. A diagnostic test — temporarily, and only if you know how to re-secure the machine, disabling real-time protection to see if the crashes stop — can confirm the link, but do this carefully and briefly, and never as a permanent "fix." The point is to identify the conflicting software, then resolve the conflict properly rather than running unprotected. See driver conflicts, since security software often installs kernel-level drivers too.

Third-party driver conflicts

A driver conflict happens when two pieces of software try to manage the same hardware, or when a driver is simply buggy or the wrong version. It's one of the most common software-side causes of crashes, and the giveaway is often in the evidence: a blue screen that names a .sys file, or a crash that starts right after a driver was installed or updated. Some drivers are supplied by device makers, some by Windows Update, and the mismatch between them can be the problem.

The approach is to identify the driver the evidence points at, then update it from the correct source or roll it back. If a stop code or an Event Viewer entry names a driver file, that's your target (see stop codes and crash events). Update it from the hardware manufacturer rather than a generic updater, and if a fresh install makes it worse, use Device Manager's rollback to return to the previous version. Where two drivers are fighting over one device, the fix is usually to have the single, correct driver in charge. This is the central driver article; the individual hardware pieces like display, network, and chipset apply the same logic to specific components.

Browser-related crashes

Most browser problems are application crashes, not system crashes — the browser dies or hangs but Windows keeps running, which is a different (and easier) problem. That said, a browser can occasionally be involved in a system crash, usually through a graphics-related setting, a misbehaving extension that loads a faulty component, or heavy hardware-accelerated video that stresses the GPU. So it's worth sorting out which kind you have.

If the whole system crashes and it tracks your browser use, the usual suspects are hardware acceleration and extensions. Test by opening a fresh private window (which disables most extensions) and by toggling the browser's hardware-acceleration setting off — if the system crashes stop with either change, you've isolated the cause. Clearing the cache and resetting the browser's settings are reasonable next steps. If it's just the browser crashing while Windows is fine, that's an app problem: disable extensions one at a time, and see telling a Windows crash from an app crash to confirm the distinction. See GPU crashes if hardware acceleration is the trigger, since that points at the graphics stack.

Game-related crashes

Crashes that happen in games are a distinct cluster, because games push the hardware — CPU, GPU, memory, and power — much harder than everyday use. That means a crash in a game can be a game bug, a driver problem, a heat problem, or a power problem, and the load is what exposes it. A crash that only happens in games and never on the desktop is the clearest possible signal that the limit is being hit under load.

Work it in order of likelihood. Start with the display/GPU driver (display driver), since that's the most common. Then check temperature under load (temperatures) — is the GPU or CPU spiking when it crashes? Then consider power (power supply), especially if it crashes even at modest settings. A useful experiment is to lower the in-game graphics settings or cap the frame rate: if the crashes stop, you've found a heat or power limit rather than a simple bug. Also make sure the game and your drivers are current, and check whether the specific game has known issues. This is where stress testing comes in to confirm whether the hardware holds up under sustained load.

Application compatibility problems

Some crashes come from a program that simply isn't compatible with your current Windows version — older software, in particular, can misbehave or destabilise a newer system. This is usually an application-level problem (that program crashes) rather than a system crash, but occasionally an incompatible program that hooks into the system can cause broader instability.

The first step is to check whether the program is current — an update often resolves compatibility issues entirely. If not, Windows has a compatibility mode that can run an older program as if it were on an earlier Windows version, which sometimes helps a legacy app behave. If a specific program is the problem and it's not essential, updating or replacing it is cleaner than forcing compatibility. Keep the scope clear: if only that program is affected, it's an app issue (see telling a Windows crash from an app crash); if the whole system crashes around that program, dig into whether it installed a driver or service that's the real troublemaker, in which case recent software and driver conflicts apply.

Startup service conflicts

Windows services run in the background and many start automatically, and a faulty or conflicting service can crash the system — particularly one that starts at boot or that two programs both try to provide. Service conflicts are a step more removed from a simple startup app, which is why they're a common "the clean boot fixed it but I don't know why" situation: the culprit wasn't a visible program but a background service.

The tool for this is the same one used for a clean boot: System Configuration, where you can disable non-Microsoft services in groups. If disabling a group of third-party services stops the crashes, you enable them back in halves until you've isolated the specific service, then track it to the program that installed it and update, configure, or remove that program. The discipline is the one-change-at-a-time rule, and the safety rule is to never disable core Windows services or your security software as part of this. This is the deeper version of startup applications — same isolation logic, aimed at the background layer. See clean boot for the full method.

Background process conflicts

Background processes are the programs and tasks running behind the scenes — sync clients, updaters, overlays, indexing, and the many helpers that modern software installs. Individually they're usually fine, but a conflict between two of them, or one that's genuinely buggy, can cause a crash that's hard to tie to anything you were deliberately doing. The clue is that the crash appears "at random" but actually correlates with a background task running.

The way to find it is to look at what's running when it crashes. Task Manager shows current processes and their resource use; Reliability Monitor and Event Viewer (see Reliability Monitor) show what was active around past crashes. If a particular process keeps appearing near your crashes, research it, update the program it belongs to, or stop it from running in the background. A clean boot is the blunt instrument that proves the point: if the crashes stop with background software disabled, a process is involved, and you narrow from there. This overlaps with service conflicts (services are a kind of background process) and startup apps; together they cover the whole "something running in the background is the cause" family.

Windows configuration changes that trigger instability

Not every crash comes from new software or a driver — sometimes it's a setting that was changed, deliberately or by another program. Power plan changes, virtual memory settings, an altered startup configuration, a changed display setting, or a tweak from a "optimisation" utility can all introduce instability. If nothing was installed but the machine started crashing, a configuration change is worth considering.

The approach is to remember or reconstruct what was changed and revert it. Power and performance settings can be reset to the balanced default (see the broader site guidance on power modes); a clean boot undoes a messed-up startup/service configuration (see clean boot); and a System Restore can roll back a batch of system changes at once (see System Restore). One specific caution: be wary of third-party "tuning" or "boost" tools that change system settings — they're a common source of exactly this kind of unexplained instability, and reverting their changes is often the fix. This article is the catch-all for the "I didn't install anything, but something changed" situation.

Crashes after installing hardware or software

Adding new hardware or software is one of the most common moments for a previously stable PC to start crashing, and the good news is that the "when did it start" answer is unusually precise. If you installed a new GPU, a new stick of RAM, a new drive, or a new program and the crashes began around then, you've essentially done half the diagnosis already — now you just confirm the new item is the cause.

The test is to remove the new item and see if the crashes stop. For software, that's an uninstall (recent software); for hardware, that's physically removing it and running the machine without it. If the crashes stop, the new item is implicated, and the fix depends on what it is: a driver to update for a new GPU, a compatibility or seating check for new RAM (see memory), or a firmware/driver check for a new drive. If removing it doesn't help, the new item was a red herring and the real cause was already present — in which case you're back to the general path, starting with the evidence in Reliability Monitor. This article is the bridge between "something changed" and "here's how to prove what it was."

Understanding stop codes

A stop code is the name Windows gives a specific kind of fatal error, and it's the single most useful piece of information a blue screen can give you. The code narrows the crash to a category of cause — memory, a driver, power, hardware — which turns an intimidating blue screen into a starting point. The exact meaning can vary a little by Windows version and by the parameters that accompany the code, so treat the code as a direction, not a verdict.

Here are some of the codes you're most likely to meet, as examples of the direction they point:

Whichever code you have, the next move is the same: confirm it in the logs (crash events) and look at what it names, then follow the direction above. If the code keeps pointing at a driver, work driver conflicts; if it's hardware-flavoured, work memory and drive health. See also minidump analysis when the code alone isn't specific enough.

Analyzing minidump files

Minidumps are the small per-crash memory snapshots Windows writes (usually to C:\Windows\Minidump), and they're the raw data behind a definitive answer. A stop code tells you the category; a minidump analysis can tell you the specific module or driver that faulted. It's the natural next step when a recurring crash has resisted the more accessible checks.

You don't read a minidump by hand — you feed it to a crash-analysis tool, which parses it and reports the faulting component. If the analysis consistently names a specific driver, that's your answer and you update or replace it (see driver conflicts). If it points at kernel or system code, the cause is deeper — system files (see SFC) or hardware. There's a learning curve to the tools, and if the analysis is inconclusive or you'd rather not dig in, a minidump is exactly the kind of evidence a technician can use. This is the "go deeper on the evidence" article, building on dump files and crash patterns.

Diagnosing recurring crash patterns

A single crash is hard to interpret; a pattern is a diagnosis. The value of this approach is that the when of a crash often reveals the why more clearly than any single log entry. Keeping a simple note — what you were doing, how long the machine had been on, whether it was under load, whether it was after sleep — builds a pattern that points at the cause.

Here are the patterns that matter most, and what each one suggests:

The method is to log the crashes for a few days using Reliability Monitor and your own notes, identify which row the pattern fits, and follow that row's "what to check." This is the analytical capstone of Category A — it turns the identification you did there into a direction. It's also what makes the rest of the guide feel less like a checklist and more like a diagnosis.

Driver Verifier considerations

Driver Verifier is a built-in Windows tool that stress-tests kernel-mode drivers to find bugs that cause crashes. It's a legitimate advanced diagnostic for when you strongly suspect a driver but can't confirm which one. The important framing is that it's a specialist tool with real side effects, so it earns its place near the end of the process rather than the beginning.

Understand what it does before you run it: Verifier deliberately puts drivers through stressful conditions to make bugs appear, which means it can cause your system to crash more than it already does — that's by design, because a crash it triggers points at the faulty driver. So you run it when you're ready to interpret the crashes it produces (typically with minidump analysis, see minidumps), and you disable it as soon as you've found what you're after. If you're not comfortable with that trade-off, or the more accessible driver checks in driver conflicts already pointed you the right way, you may not need Verifier at all. It's a "when the easy path is exhausted" tool, and it's worth knowing it exists before you assume a driver problem is unsolvable.

Hardware stress testing

Stress testing means deliberately loading a component — CPU, GPU, memory, or the power delivery to them — to see whether it holds up or fails. It's how you confirm a hardware suspicion that everyday use only hints at: a crash that only happens under load is a strong candidate for a controlled test. The value is turning "it might be the GPU" into "the GPU faults at X temperature / under Y load."

Approach it with care and in order. Test one component at a time, watch temperatures (see temperatures), and stop the moment you see instability — the goal is to confirm the fault, not to damage the hardware. A CPU that throttles or crashes under a sustained load points at cooling; a GPU that faults under a graphics load points at the card, its driver, or power. Keep runs reasonably short and monitor the temps throughout. If a component fails a stress test it should normally pass, that's meaningful evidence of a hardware limit, and it feeds directly into the decisions in recovery options and the "when to get help" section — a failing component is a replace-or-service situation, not a settings one.

Checking storage health

This is the advanced companion to drive health, focused on the actual health-checking process. The core idea is SMART data: the drive's own sensors report on its condition, and reading them is the difference between guessing the disk is fine and knowing it's degrading. A drive that's quietly failing is a classic hidden cause of random crashes, so this check is worth doing whenever the software-side fixes have come up short.

Use reputable disk-health software (or the drive manufacturer's own tool) to read the SMART attributes and the overall health status. Look for a "caution" or "failing" status and for attributes like reallocated sector count that are rising over time — those are warnings, not something to watch and wait on. The response to a failing drive is consistent: back up your data now, and plan to replace the drive. A healthy result, by contrast, lets you rule storage out and focus elsewhere. Pair this with a file-system check in checking the file system — one addresses the physical disk, the other the logical file structure, and together they give you a complete picture of whether storage is your problem.

Checking memory stability

Memory is the component that most often causes crashes that look random, which is why a dedicated stability check is worth its own article beyond the quick diagnostic in defective memory. The point of a stability check is to be thorough enough to catch an intermittent fault that a short test misses, because marginal memory is exactly the kind that passes a quick pass and fails later.

The standard approach combines a longer memory test with physical isolation. Run a full (not quick) memory test and let it complete multiple passes; then, if you have more than one module, test them one at a time so a failure ties to a specific stick. If errors only appear with one particular module, that module is bad and should be replaced. If the memory is genuinely unstable and you're not in a position to replace it immediately, be aware that no software fix will make faulty RAM reliable — it's a hardware condition. This is the definitive answer for the random crash that everything else has failed to explain, and it's one of the more satisfying diagnoses when it's the cause, because the fix is simple.

System Restore versus Reset

These two options are often confused, and the difference matters a lot. System Restore rolls back system changes — drivers, updates, some software — to a past point, while keeping your personal files and most of your programs. Reset is a much bigger step: it reinstalls Windows, and depending on your choice it either keeps your files or wipes everything. One is a rewind; the other is a rebuild.

Use System Restore first whenever there's a plausible restore point before your problems started — it's faster, less disruptive, and it directly undoes whatever change likely caused the instability (see System Restore). Reach for a Reset only when Restore isn't available or hasn't helped, and the system is too far gone to fix piecemeal — that's covered in When to use Windows Reset. The decision between them is really a decision about how damaged the system is: a recent, identifiable cause points to Restore; a long-decayed, generally broken system points to Reset. Either way, a backup first, per recovery strategy.

When to use Windows Reset

Windows Reset reinstalls the operating system and is the right tool when the software side of things is too tangled to fix with individual repairs — but it's a heavy hammer, so it belongs late in the process, not early. The situations where it's genuinely appropriate are a system that's accumulated a lot of conflicting changes, one that's crashing in a way that no targeted fix has resolved, or one you want to hand off or sell in a clean state.

Two things to get right. First, understand the two flavors: "Keep my files" preserves your personal documents but removes your apps and settings, while "Remove everything" is a full wipe. Choose based on whether you're trying to save a working machine or start clean. Second, and critically, a Reset fixes software problems — it will not fix a bad stick of RAM or a failing drive, so if your evidence points at hardware (see memory, drive health), a Reset just delays the real fix. Back up before you start, and treat Reset as the software-side last resort, sitting just before a clean install in the recovery ladder. See Restore versus Reset for where it sits relative to the lighter option.

When a clean Windows installation is appropriate

A clean install is the most complete software reset available: it erases the system drive entirely and installs Windows from scratch, leaving nothing of the old installation behind. It's more thorough than a Reset and the right answer in specific situations — when you want the absolute cleanest possible system, when a Reset hasn't fully resolved things, or when you're repurposing or selling the machine.

The trade-offs are real, so it should be a deliberate choice. You'll reinstall your applications and reconfigure your settings, and it erases the drive completely, so a full backup of everything you want to keep is not optional — it's the prerequisite. It's also only justified once you've ruled out hardware: a clean install on a machine with failing RAM or a dying disk just moves your problems to a fresh Windows. If you've worked through the diagnostics, confirmed the hardware is sound, and the software is simply too far gone, a clean install is a clean, final software solution. See recovery strategy for how to prepare, and Windows Reset as the lighter alternative that solves many of the same problems.

Creating a recovery strategy before major repairs

Before you do anything that's disruptive — a file-system check, a Reset, a clean install, a firmware update — you owe yourself a recovery strategy. The principle is simple: make sure you can get back to a working state, and that your data is safe, before you take the step that might not be cleanly reversible. This is as much a habit as a task, and it's what separates a confident repair from a risky one.

In practice, a strategy has a few parts. Back up the files you can't afford to lose, to somewhere other than the drive you're about to work on. If System Restore is available, note (or create) a restore point before you start, so you have a software rollback (see System Restore). Write down what you're about to change and why, so you can reverse it or explain it later. And be honest about your exit: if a repair goes wrong, do you know how to get back? Having that answer before you start — a known-good restore point, a backup, a recovery drive, or a clean-install plan (see clean install) — is what makes the bigger repairs in this category something you can do with confidence rather than anxiety.

When third-party diagnostic tools help (and when they don't)

There's a wide ecosystem of third-party tools for temperature monitoring, memory testing, disk health, and crash analysis, and some of them are genuinely useful — often more thorough than the built-in equivalents. A good temperature monitor, a serious memory test, and a reputable disk-health tool all have real value in the advanced diagnostics here. The key is knowing which tools to trust and which to skip.

The rule of thumb: use well-known, reputable tools from credible sources for specific jobs (monitoring temps, testing memory, reading SMART data), and be sceptical of the "one-click PC fix" utilities that promise to find and repair everything. The latter category is a common cause of the very instability this guide is about, because they make sweeping changes to system settings (see configuration changes). A diagnostic tool should inform your decisions, not make them for you. When in doubt, prefer the built-in Windows tools covered in this guide and the manufacturer's own utilities, and treat any third-party tool that wants to "optimize" or "clean" your system as a potential problem rather than a solution.