My Computer Keeps Restarting: Complete Troubleshooting Guide

What "keeps restarting" really means

The word "restart" quietly covers two very different events, and separating them is the foundation of everything that follows. In one case, Windows itself decides to reboot — perhaps it hit an error and is configured to restart, or an update has finished and needs a boot to take effect. In the other, the machine simply loses power and comes back, with Windows having no say at all. A software-driven restart and a power-driven restart have different causes and different fixes, so the first thing to establish is which one you're actually experiencing.

The "keeps" in "keeps restarting" is itself a clue. A one-off reboot after an update is normal; a machine that does it repeatedly is signalling that a condition is persisting — a component that runs too hot, a part that's degrading, a driver that fails the same way every time, a power supply that can't hold up. That persistence is what makes this a pattern you can diagnose rather than a random fluke you can only hope stops. The rest of this guide is about catching that pattern and following it to its source.

Is it Windows or the hardware restarting?

This is the single most useful early question, and the answer steers you to the right half of the guide. A Windows-initiated restart usually announces itself: you may see a blue screen, or the screen dims and a brief "Shutting down" sequence plays, and then the machine is back. The operating system was alive right up to the end. A hardware restart is abrupt — the screen goes instantly black with no shutdown, no blue screen, no goodbye, and a second or two later the PC is on again. Windows didn't get the chance to react; the power simply dropped.

Watch the moment it happens if you can — does the screen fade and sequence, or cut to black? That single observation narrows the field a lot. You can confirm it afterwards from the logs: a Kernel-Power event in Event Viewer that says the system rebooted without cleanly shutting down points to a power or thermal event, while a BugCheck event means a blue screen occurred (see Event Viewer). If it's the abrupt black-screen kind, the hardware section — power, heat, memory, disk — is where your time is best spent. If it's the blue-screen kind, start with reading the code.

Stop Windows from hiding the crash

By default, Windows is set to restart automatically after a serious error, which is friendly for a quick return to work but actively unhelpful for diagnosis: it reboots the machine before you can read the blue screen, erasing the one piece of evidence that names the problem. The single highest-value thing you can do early on is switch that off, so that the next failure stops and shows you a screen with a code instead of silently cycling.

To change it, open System Properties (search "Advanced system settings"), go to the Advanced tab, click Settings under "Startup and Recovery", and under System failure uncheck Automatically restart, then confirm and reboot. Nothing about this touches your files or settings — it only changes what Windows does when it would otherwise have hidden a crash. Once it's off, the next time the problem occurs you should get a blue screen that stays on screen; photograph it, because you may not get long to read it. If it still restarts with no blue screen at all, that's meaningful in itself — it points away from a software crash and toward power or hardware, so carry that into the next step.

Reading the blue screen and stop code

When you've got Windows to show the screen, the most important thing on it is the stop code — a name like IRQL_NOT_LESS_OR_EQUAL or CRITICAL_PROCESS_DIED — and, if present, a "What failed" line that often names a specific driver file. The code groups the crash into a category of cause, which turns an intimidating full-screen error into a starting direction. Note the exact code and any driver filename before the machine reboots; a quick photo with your phone is a good habit, because the screen can disappear fast.

Here's what some of the common ones tend to point toward, as a guide rather than a verdict (the exact cause still depends on your specific situation):

Whatever the code says, the follow-through is the same: confirm it in the logs (Event Viewer) and see what it names, then follow the direction — a driver leads to rolling it back, a memory- or hardware-flavoured code leads to memory and power. If your restarts are the abrupt black-screen kind with no blue screen at all, skip ahead to the hardware section, because the code you're looking for simply isn't being shown.

Finding the pattern: when does it restart?

A single restart is hard to read; a pattern is a diagnosis. The when of a restart often reveals the why more clearly than any log entry, so it's worth keeping a simple note for a day or two: roughly the time, what you were doing, whether the machine was under load, whether it had just woken from sleep, and whether it was shortly after an update. Even a rough log will usually start to show a shape.

Reliability Monitor (search "Reliability Monitor") does part of this for you — it plots your failures on a day-by-day timeline alongside Windows Update activity, so you can often see a restart sitting right next to an update that landed just before it. Match the pattern you see to what it suggests:

Identify which row your machine fits and follow its "what to check" column. This is the analytical bridge from "it restarts" to "here's where to look next," and it's what makes the rest of the guide feel like a diagnosis rather than a checklist you work top to bottom.

A bad Windows Update

Timing is the cheapest diagnostic you have, and "the restarting 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 restarts that follow are often caused directly by that change rather than by anything you did. Windows also sometimes restarts itself to finish applying an update, so a fresh update can look like a new habit of rebooting.

First confirm it: open Settings → Windows Update → Update history to see what landed and when, and line it up against when the problem began (Reliability Monitor makes this easy). If a specific recent update lines up, you can uninstall it from that same Update history page (Uninstall updates), or from the Recovery Environment's "Uninstall Updates" option if you can't get into Settings. If the update also dropped a driver, you may need to roll that driver back as well (see problematic driver). Don't simply turn Windows Update off to "fix" this — that leaves you unpatched and the underlying cause may remain. The goal is to remove or work around the specific change while staying current.

A problematic driver

Drivers are the software that tells Windows how to talk to your hardware, and a driver that's buggy, outdated, or the wrong version is a leading cause of restarts. The graphics driver is the most common offender — a GPU driver that can't handle a workload can trigger a reset that escalates into a reboot, especially in games — but chipset, network and storage drivers can do it too. The giveaway is often in the evidence: a stop code that names a .sys file, or restarts that began right after a driver was installed or updated.

The fix is to identify the driver the evidence points at, then update it from the correct source or roll it back. Open Device Manager, expand the relevant category, right-click the device, choose Properties, and on the Driver tab you can either Roll Back Driver (if a previous version is available) or Update driver. Prefer the hardware manufacturer's driver over a generic updater. A useful confirming test is Safe Mode: if the restarts stop there, a non-essential driver or piece of software is involved. Where a specific driver file is named in the logs, that's your target — update, replace, or roll back that one.

Isolating software with Safe Mode

Safe Mode starts Windows with only the minimum of drivers and no third-party startup software, which makes it the cleanest way to answer the question "is this my software, or the system?" If the machine is stable in Safe Mode but restarts in normal mode, you've just proven the cause is third-party software or a non-essential driver — a big step forward, because it rules out a lot of the deeper and more frightening possibilities in one go.

You can usually get there from Settings → System → Recovery → "Advanced startup" (Restart now), then Troubleshoot → Advanced options → Startup Settings → Restart, and press 4 for Safe Mode or 5 for Safe Mode with Networking if you need to download anything. Use it to do the one change that's likely to help — roll back a driver, disable a startup item, uninstall a suspect program — then reboot normally and test. The discipline that keeps this from becoming a maze is to change one thing, leave Safe Mode, and see whether the restarts stop before you change the next. If it restarts even in Safe Mode, the cause is deeper — a core driver or system component — so move on to system file checks and the hardware section.

Startup apps and recent software

Startup applications all launch together at login, and an unstable one among them can destabilise the system shortly after you sign in. You don't have to uninstall anything to stop them launching: Task Manager's Startup apps tab lets you set an item to Disabled, which simply stops it starting at login while leaving the program fully usable on demand. That's a low-risk, fully reversible change, which is exactly what you want for an early test.

Disable the less-essential items in a batch (game launchers, chat apps, media players, vendor utilities), reboot, and see whether the early restarts stop. If they do, you've found the group — re-enable them one at a time to name the specific app, then update, repair, or uninstall it. This is the everyday version of the same isolation logic as Safe Mode, and it resolves a surprising number of "restarts right after login" problems on its own. If nothing here is the cause, the next step is to look at whether a specific program or background service is the troublemaker rather than a startup item.

A specific program or background service

Sometimes the cause is a single program — not a startup item, but something that crashes the whole system when it runs, or a background service it installed that conflicts with something else. The clue is correlation: does the restart tend to happen while a particular program is open, or shortly after you start it? If the answer is yes, you've essentially done half the diagnosis. Keep the distinction clear, though — a program whose own window just closes is an application crash (a smaller problem), whereas a program that takes the whole machine down with it is a system-level conflict worth resolving.

Test the link directly: run the machine with that program closed and see if the restarts stop; if they do, the program is implicated. Then update it to the latest version, repair it, or — if you don't strictly need it — uninstall it. For background services specifically, the same isolation approach applies: a clean boot (disabling non-Microsoft services in groups) will prove a service is involved, and you can narrow from there. This step overlaps with startup apps and the Event Viewer, which can name the faulting module when you're not sure which program is responsible.

Corrupted system files (SFC and DISM)

System files can become damaged by an interrupted update, a power loss, or failing storage, and a damaged core file can destabilise Windows broadly enough to cause restarts. The good news is that Windows ships with tools that both detect and repair this corruption, and they're safe to run — they don't touch your personal files. The standard sequence is to repair the underlying store first with DISM, then repair the individual files with SFC.

Open Command Prompt or PowerShell as an administrator and run DISM first:

DISM /Online /Cleanup-Image /RestoreHealth

Let it reach 100% (it uses Windows Update, so it needs a connection), then run SFC:

sfc /scannow

Read what SFC reports. If it says it repaired corrupt files and the restarts stop, that was the cause. If it found problems it couldn't fix, the component store is the likely source and a further DISM pass — or eventually a repair install — may be needed. If it found nothing, that doesn't rule out your problem; it just means the protected system files are intact, so keep working through the other causes. See also failing disk, because corruption that keeps coming back often has storage at the root.

Malware and suspicious software

Malware is a less common cause of restarts than drivers or heat, but it's worth a check, for two reasons. Some infections — notably cryptominers — deliberately max out the CPU and GPU, which drives temperatures up until the machine thermally restarts, making it look like a hardware problem when the real cause is a program. Other malicious behaviour can include unexpected shutdowns or restarts, or the installation of rogue startup items and services. If the machine has recently started behaving oddly in ways beyond just restarting — slowness, unknown programs, fan that never stops — that tilts the balance toward checking for infection.

Run a full scan with Windows Security (Windows Defender), which is built in and sufficient for most people, and look for anything it flags. While you're there, glance at what's running and what starts up: unfamiliar processes in Task Manager or unexpected items in the Startup apps list are worth investigating. One important caution — avoid downloading random "PC cleaner" or "antivirus" utilities from the web to chase a problem; that category is itself a frequent source of the very instability you're trying to fix. A reputable, well-known scan is the right tool here; a sketchy download is the wrong one.

Using Event Viewer to find the cause

Event Viewer is the detailed logbook behind Reliability Monitor, and it's where you go to confirm what kind of restart you've been dealing with and what was happening around each one. Open it (search "Event Viewer"), expand Windows Logs, and select System. Then look at the events around your restart times — specifically the entries with a red error icon, and two sources in particular.

The two that matter most for a restarting machine are quite different from each other, and telling them apart is the diagnosis:

If you're seeing Kernel-Power events with no preceding BugCheck, that's a strong signal the restarts are power- or hardware-driven rather than software crashes — head to the hardware section. If you're seeing BugCheck events, read their codes and follow them as described in reading the blue screen. The pattern of which events appear is itself the answer, and it's the "read the evidence" step the whole guide is built on.

Overheating

When a component gets too hot, the system first throttles it — slowing it down to stay within safe temperatures — and if it gets hot enough it forces a shutdown or restart to prevent damage. That protective shutdown looks exactly like a random restart, which is why heat is such a common hidden cause. The pattern to look for: the problem appears after the machine has been running a while, or specifically under load (gaming, video, a render), and the fan is working hard. A machine that runs fine for twenty minutes and then restarts is a classic thermal case.

The right approach is to measure rather than guess. Run a lightweight temperature monitor and watch the CPU (and GPU, if you have one) while you do the thing that normally triggers a restart. If a temperature is climbing into a high range right before the restart, cooling is your problem. The safe, common fixes are clearing dust from the vents, making sure the fans are actually spinning, keeping the air vents unobstructed, and using a laptop on a hard flat surface. Where the fix is dried-out thermal paste or a physically failing fan, that's a service-level job rather than something to keep pushing on. This is the diagnostic half; the physical cleaning and inspection is the next step, in fans, vents and dust.

Fans, vents, and dust

Dust is the physical cause behind most overheating problems, and it's also one of the most satisfying to fix. Over time, dust builds up on the heatsink and in the vents, insulating the components and blocking airflow until they run hotter than they should. A machine that used to run cool and quiet and has gradually gotten louder and warmer is usually telling you this.

With power safely off, the checks are straightforward: are the fans actually spinning when the machine is on (a silent, still fan is a failed fan)? Are the air vents blocked by dust, a soft surface, or where you've placed the machine? Is there a thick layer of dust on the CPU heatsink or fan blades? Carefully clear the dust — compressed air in short bursts works well, holding the fan blades still so they don't spin up and over-rotate. If a fan is physically dead, or the dust problem is deep in the heatsink where the thermal paste has likely dried out, that's the point to bring in a service. Start by confirming the diagnosis in overheating so you know cleaning is actually what will help.

Power connections and the power supply

A failing or underpowered supply is one of the causes that most closely mimics a "crash" while actually being the machine losing power. Its signature is a restart with no blue screen at all — the system just drops and comes back, often under load, when the components are drawing more current than the supply can comfortably deliver. If you've turned off automatic restart (see stop automatic restart) and still see no blue screen, power is a strong suspect, because a genuine software crash would have shown one. A Kernel-Power event with no preceding BugCheck in Event Viewer reinforces this.

Start with the easy, safe checks: is the power cable firmly seated at both ends, and does the machine behave the same on a different wall outlet? On a laptop, a failing or under-rated power adapter can cause exactly this — try a known-good compatible adapter. The harder question is whether the power supply unit itself is degrading, which you can't easily measure without proper tools. The practical test on a desktop is to swap in a known-good, compatible supply — if the restarts stop, you've found it. Treat that step with care: a power supply is the one part with live, stored electricity, so unplug and drain the system first, and if you're unsure, that's a job for a technician. A marginal power supply is a replace-the-part decision, and it's worth a professional assessment before you keep loading a machine that's dropping power. See when to get help for the threshold.

RAM and memory

Memory is a deceptively common cause of restarts, and its signature is that they look random. A faulty section of RAM corrupts the data that Windows and its drivers rely on, which can produce restarts, freezes, and blue screens with no obvious trigger — the machine seems fine, then just drops. If your restarts are intermittent, come with memory-flavoured stop codes, and no software change fixes them, memory should be high on the list. It's one of the cheaper hardware problems to confirm and, when it is the cause, one of the cheaper to fix.

The way to find out is a memory test. The built-in Windows Memory Diagnostic (search "Windows Memory Diagnostic") reboots the machine and runs a pass over the RAM, reporting any errors it finds; a longer third-party test is more thorough. A pass doesn't fully prove the memory is good — it's relatively quick — but a fail is a strong signal. The most conclusive method is physical isolation: if you have more than one stick, test them one at a time, and if errors only appear with a particular module installed, that module is the faulty one and should be replaced. This is the article to come back to for any random restart that every software fix has failed to touch.

Removing recently added hardware

Adding new hardware — a second stick of RAM, a new graphics card, an extra drive — is a classic moment for a previously stable PC to start restarting, and the "when did it start" answer is unusually precise: it began around the time you added the part. The good news is that makes the diagnosis straightforward. The test is to remove the new item and run the machine without it; if the restarts stop, the new part (or how it's installed or configured) is the cause.

If the new item is implicated, the fix depends on what it is. For a new stick of RAM, reseat it firmly, try it in a different slot, and test whether it's compatible with the rest of your memory — mismatched modules can be unstable. For a new graphics card, check that it's fully seated and that its power connectors are attached, and update its driver. For a new drive, check its cabling and whether it's the boot drive or a secondary one. If removing the part doesn't change anything, it 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 finding the pattern and Event Viewer. As with any internal work, unplug and drain the system first (see the safety note in fans, vents and dust).

A failing SSD or hard drive

Because Windows and everything on it live on the storage drive, a drive that's degrading can cause restarts, boot failures, and freezes — sometimes with a stop code like an inaccessible boot device, as Windows struggles to read the system it's running from. A failing disk is a "hidden" cause in the sense that it can produce symptoms that look random or software-related for a while before it gives itself away. The more subtle the failure, the longer it can masquerade.

The check is the drive's own health data (SMART), readable with the drive manufacturer's tool or reputable disk-health software. A status of "caution" or "failing," or attributes like a rising reallocated-sector count, are warnings to act on, not watch. The response to a genuinely failing drive is consistent: back up now, and plan to replace it — you don't repeatedly repair a dying disk, you replace it (an SSD is a nice upgrade if you're on an older hard drive). This is the article to reference whenever a random restart has resisted every software and memory fix, because a degrading disk is the classic "invisible" hardware cause. See when to get help if the replacement feels beyond you.

BIOS/UEFI and hardware settings

Firmware (BIOS/UEFI) sits at the very bottom of the stack, handling boot and how the hardware is configured at the lowest level. Two things here can cause restarts. The most common is an aggressive configuration — an overclock, or an XMP/DOCP memory profile that pushes the RAM a little faster than it's actually stable at — which produces exactly the kind of intermittent, load-related instability described in this guide. The less common is a firmware bug that a vendor has since fixed with an update.

The safe first move is to test with everything at default: reboot and enter the firmware setup (usually Del or F2 at power-on), then choose the option to load optimized/default settings, save, and exit. If the restarts stop, you've found an overclock or memory profile that was too aggressive — you can then dial it back to a stable setting rather than losing the performance entirely. Be more cautious with firmware updates: they're worth doing only from the official manufacturer source, only when the vendor indicates an update is warranted, and only with stable power, because an interruption during a firmware flash is a serious risk. If you're unsure whether firmware is involved, that's a reasonable moment to bring in a technician. This pairs naturally with overheating and RAM, since an unstable memory profile and a thermal limit can look alike from the outside.

Recovery options, in order

When the targeted fixes above haven't solved it — or the system is too far gone to repair piecemeal — you move up a recovery ladder where each rung is more disruptive than the last. The principle is to use the lowest rung that actually solves the problem, because the higher rungs cost more of your time and, in some cases, more of your data. Back up before you attempt any rung below the first.

The ladder, in order:

1. Targeted fix. Update or roll back the specific driver, remove the specific program, apply the specific setting. Least disruptive — always try first.
2. System Restore. Roll back system changes to a known-good point, keeping your files. Reaches back in time to before the problem started.
3. Uninstall a recent update. Remove the specific Windows update that caused the problem (see bad Windows update).
4. Repair install. Refresh Windows in place, keeping your files and most apps, to replace damaged system files. A step above SFC/DISM.
5. Windows Reset. Reinstall Windows, optionally keeping your files. The software-side last resort.
6. Clean install. Wipe the drive and install from scratch. The most complete software reset.

The one caveat that runs through all of this: a Reset or clean install fixes software. It will not fix bad RAM, a failing disk, or a dying power supply — if your evidence points at hardware (see the tests in RAM, failing disk and power), a reinstall just delays the real fix. So confirm the hardware is sound before you reach for the big software options, or you'll be reinstalling onto a machine that's still going to restart.

When to get professional repair

Some restarts are beyond a home fix, and recognising that is part of troubleshooting well rather than a failure. These are the signs that it's time to stop and bring in a technician: your memory or disk tests fail, pointing at a component that needs replacing; the restarts happen only under load and point at a power supply or GPU that needs proper equipment to test; you can't get into Windows or the Recovery Environment at all; or a firmware update is indicated, which is risky to attempt without confidence. A failing power supply, motherboard, or CPU in particular is squarely in professional territory.

Before you hand the machine over, everything you've done in this guide gives you a real head start. The stop code, the restart pattern (under load, after sleep, random), and the results of the memory and disk checks are all useful evidence to share, and they can save a service visit or at least make it more productive — a technician who knows "it's a hard restart under load with a Kernel-Power 41 and clean memory" is far better placed than one starting from scratch. And weigh the timing: the cost of a failing component caught early is almost always less than the cost of the data loss or extended downtime that comes from keeping to push on with a machine that's clearly degrading. If you're unsure whether it's worth a call, the fact that you've worked through the software steps and the non-invasive hardware checks and it's still happening is itself a reasonable reason to make that call.