I Keep Getting a Blue Screen: Complete Troubleshooting Hub

I keep getting a blue screen — where should I start?

A recurring blue screen is a report, not a sentence — and the first job is to read it, not to fix anything yet. The screen (or the record of it, if it has already gone) contains the single most useful piece of evidence you will get: the stop code, and often a "What failed" line naming a driver file. So step one is to capture that: photograph the next screen, or, if it has already vanished, recover the code from Reliability Monitor and Event Viewer as shown in finding the cause of a recent BSOD.

The second job is pattern. When the crash arrives — under load, after an update, when a specific program runs, at boot — tells you which half of this hub to work. Recurring crashes are almost always an ongoing condition: a driver that fails the same way, unstable memory, heat building to a limit, a degrading disk. Patterns are how you catch ongoing conditions, and they take one day of noticing to establish.

The recommended order, in brief: capture the code → disable automatic restart so the next crash stays on screen → read the timeline → match the code and pattern to a category → work that category's articles. If the straightforward categories come back clean, advanced diagnostics teaches you to read the crash dumps Windows writes. The start-here path above is this same sequence, with links.

What a blue screen is (and isn't)

A blue screen of death (BSOD) is Windows's last-resort safety mechanism. When the kernel reaches a condition it cannot safely recover from — a driver touching memory it shouldn't, a critical process dying, a hardware error the platform reports — it stops, writes a crash dump, and restarts. It is designed to prevent silent data corruption, which means the screen itself is a crash report, not a malfunction of the reporting system.

It is worth separating from an application crash. When a game or program crashes, only that program closes and you stay at the desktop. When the machine blue-screens, the whole operating system has stopped — which is why the causes live in lower layers (drivers, kernel components, hardware) and the fixes live in different places than "close it and reopen it."

A single BSOD is not a diagnosis; recurrence is. Occasional crashes happen on healthy systems. A machine that blue-screens repeatedly has a continuing cause — most commonly a driver, unstable memory, a degrading disk, heat, or power — and this hub is organized around finding that cause rather than suppressing the screen.

How to read a Windows blue screen error code

A modern blue screen has three useful parts. The stop code — a name like MEMORY_MANAGEMENT or VIDEO_TDR_FAILURE — names the category of failure, not the specific culprit; the same code can come from a driver, from RAM, or from a disk. An optional "What failed:" line names a specific file, usually a driver, and is far more specific. And a line about a memory dump being written, which tells you where the detailed evidence went (see analyzing minidumps).

If the screen disappears before you can read it — Windows restarts automatically by default — there are two fixes. Turn off that automatic restart so the next crash stays on screen (the setting is covered step by step in the keeps-restarting tutorial). Or recover the code afterwards: Reliability Monitor lists the stop code for each crash, and the BugCheck entry in Event Viewer carries it too.

Use the code the way a mechanic uses an engine warning light: it points at a system, and you check that system. The stop codes section below covers the common codes directly, with the check order for each. And if the "What failed" line names a .sys file, jump straight to identifying the driver — that is the most specific pointer the screen can give you.

How to find the cause of a recent BSOD

Windows keeps the evidence after the screen is gone, in three places: Reliability Monitor (a friendly timeline), Event Viewer (the raw log, with the stop code and often a faulting module), and the crash dumps themselves (small .dmp files in C:\Windows\Minidump). For a recent crash the timeline tools are fastest; for anything older or subtler, the dump is the definitive record.

The order: open Reliability Monitor and find the crash marker — its details show the stop code and a link into Event Viewer. In Event Viewer's System log, open the BugCheck error at that time; the description carries the code and, frequently, the module name. If you need more, the file in the Minidump folder with the matching timestamp is the dump for that crash, ready for the analysis in minidumps and WinDbg.

One caution: if the machine has crashed several times, don't assume the newest dump is the interesting one. Compare the codes across the last few crashes — a repeating code is a persistent fault with a persistent cause; a scatter of different codes shifts suspicion toward memory or power (RAM, power).

How to use Windows Event Viewer for BSOD troubleshooting

Event Viewer is the raw record behind the friendlier tools, and for blue-screen work the entry that matters is the BugCheck event under Windows Logs → System. It records the stop code, its parameters, and — critically — often the name of the module Windows believes was involved.

To read it: open Event Viewer, expand Windows Logs, select System, and find the red BugCheck error at the time of the crash. The general description carries the code; the details of the event carry the parameters and any faulting file. Look for the companion signal too: a Kernel-Power 41 at the same time with no preceding BugCheck means the system lost power rather than crashed — a different path entirely (unstable power).

Practical advice: filter to errors, and read the cluster of events in the minutes before each crash, not just the BugCheck line. A driver service failing, a disk controller warning, or a memory-management error shortly before the crash is frequently more informative than the crash entry itself — the BugCheck is the conclusion, and the preceding errors are often the evidence for it.

How to check Windows Reliability Monitor

Reliability Monitor (search "Reliability Monitor", or run perfmon /rel) is the most approachable timeline Windows ships: every crash, failure, and significant event plotted day by day, with an overall stability index. A recurring blue screen shows up as a series of markers — and the spacing between them is diagnostic in itself, because it shows you the pattern (random, load-related, post-update) without any log-reading.

Click a crash marker and the details pane shows the stop code plus a link to the matching Event Viewer entry. Its particular value for blue-screen work is that Windows Update activity plots on the same timeline: if your crashes cluster right after update entries, that is a strong lead you can confirm in a minute (BSODs after an update).

It is a triage tool rather than a deep one — it tells you when and which code, but not why. When the code points somewhere, follow it to the matching article in this hub; when you need more detail than the marker shows, the linked Event Viewer entry is one click away.

How to run System File Checker (sfc /scannow)

System File Checker (SFC) repairs Windows's protected system files: it compares each against a cached copy and replaces any that don't match. That makes it the correct first tool when a crash might come from corruption — damaged system files after a bad shutdown, a failed update, or a disk error are all things it can find and fix.

Run it from Command Prompt or PowerShell as an administrator:

sfc /scannow

Let it finish (10–30 minutes is normal) and read the result. Three outcomes matter: it found no integrity violations (system files are intact — the cause is elsewhere); it repaired some files (test the machine — if the crashes stop, that was a real contributor); or it found corruption it couldn't repair (that points at the component store, and the next tool is DISM).

Know its boundary: SFC does not touch third-party drivers or hardware, so a driver or RAM crash will usually return "no violations." That is a useful negative result — it rules a whole layer out — but it is not a verdict.

How to use DISM to repair Windows

DISM (Deployment Image Servicing and Management) repairs the Windows component store — the underlying package health that SFC depends on. When SFC says it found corruption it can't fix, or when crashes appeared around a bad update, DISM is the next tool, because it repairs the source that SFC copies from.

From an administrator prompt, run it (it uses Windows Update to source healthy components, so the machine needs a connection):

DISM /Online /Cleanup-Image /RestoreHealth

Let it reach 100%, then run SFC again so it can repair individual files from the now-healthy store. If both complete cleanly and the crashes continue, you have ruled file corruption out as a cause — which meaningfully narrows the field toward drivers, memory, or hardware. If DISM itself fails to find sources, the store damage is severe and a repair install (see reset or reinstall) is the practical next rung.

The risk note is brief: DISM touches system packages, not your files, and it is slow. Nothing here is destructive — but like any system repair it wants to run to completion uninterrupted.

How to update device drivers safely

A driver update is among the most common blue-screen cures — and among the most common causes, depending on whether the new driver is better than the one you have. The safe order for sources: Windows Update first (it carries tested, signed drivers for most hardware), then the device manufacturer's support site for your specific model. Graphics drivers in particular should come from NVIDIA, AMD, or Intel — or your PC's vendor — not from generic "driver updater" tools, which are themselves a frequent source of the instability they promise to fix.

For a specific device: Device Manager → expand the category → right-click the device → Update driver. For a GPU, prefer the vendor's installer (with its "clean install" option where offered) over the generic one. After updating, verify the way that matters: run the workload that used to crash. A driver fix is only real if the crash stops under the conditions that caused it, not merely if the machine has booted since the install.

If the update makes things worse, that isn't a dead end: rolling back restores the previous version in one step. And if you're not yet sure the driver is the cause at all, confirming which driver the crash points at turns an update from a guess into a test.

How to roll back a recently updated driver

If the crashes started right after a driver update — one you installed, or one Windows pushed — the fastest fix is often the previous driver. Windows keeps a copy of the last installed version for most devices, and restoring it is a single action: Device Manager → the device → Properties → Driver tab → Roll Back Driver, give a reason, and reboot.

Two caveats. Roll Back is only available while the previous version is still stored — after a second update it's gone, and your fallback is reinstalling a known-good version from the manufacturer. And if the crash evidence doesn't actually name this driver, rolling it back is a guess; confirming the driver first makes the rollback a test instead of a lottery. The evidence sources are the "What failed" line on the screen, the BugCheck entry in Event Viewer, and the dump.

After a successful rollback, stop Windows from just pushing the bad version back: recent Windows builds let you exclude a driver from Windows Update delivery under the Advanced update options, and the manufacturer's installer can also pin a specific version. Then re-run the workload that used to crash, a few times, before you call it fixed.

How to identify the driver causing BSODs

Before updating or rolling anything back, confirm which driver the crash points at. There are three tiers of evidence, in increasing rigor: the "What failed: xxx.sys" line on the screen; the BugCheck entry in Event Viewer (which often carries the same module name); and the crash dump, whose analysis names the faulting module with the most precision (minidumps, WinDbg). All three are worth checking, because the screen vanishes and the logs sometimes omit the module.

A .sys name tells you the driver — and often the vendor, by pattern. Vendor graphics drivers have distinctive names (NVIDIA's is nvlddmkm.sys; AMD's begin with atikmdag), while names like tcpip.sys or ntoskrnl belong to the operating system itself. An OS file named in a driver-flavored code usually means the real culprit is a third-party driver that referenced kernel memory, or corruption — which is SFC/DISM territory rather than a driver update.

Once you have the name, the branch is mechanical: a newer vendor version exists → update; the crashes started after an update → roll back; the module isn't a driver you recognize → search the filename, because unknown modules are frequently third-party utilities, anti-cheat components, or virtual drivers, and uninstalling that software is often the fix. This article is the hub of the driver branch: every driver stop-code article below funnels back into it.

How to troubleshoot blue screens from networking drivers

Network-stack crashes have a fingerprint: they cluster around network activity — connecting, transferring, or waking the adapter — with a network driver or a network-stack component named in the dump (adapter drivers, or names from the NDIS layer). They can also surface as a generic IRQL code with no obvious pattern, which is why the dump is worth reading when network-related crashes resist the simple explanation.

The path is the standard driver path aimed at the adapter: update the Wi-Fi or Ethernet driver from the PC or adapter vendor (Windows Update first), roll it back if an update preceded the crashes, and verify with the network under real use — transfers, video calls, the workload that used to crash. If the evidence instead names the system's tcpip.sys, treat that as a corruption signal: run SFC and DISM rather than hunting for a driver to update, because that file is part of Windows itself.

One less common branch: crashes that happen only while a specific network application runs — a VPN client, remote-desktop tool, or third-party firewall — point at that software's network filter driver. Uninstalling or updating the application is the test, and it is the same logic as software-related crashes applied to the network stack.

How to troubleshoot blue screens caused by USB devices

USB-related crashes tend to have a clean trigger: they happen when you plug or unplug a device, or they occur only while a particular one is connected. Dumps in this class usually point at the USB host-controller drivers (the xusb21/xusb22 family for USB 3) or at the device's own driver — the controller rather than the stick, more often than not.

The test is physical and cheap: shut down, unplug everything USB that isn't keyboard and mouse, boot, and use the machine. If it holds, reconnect devices one at a time until the crash returns — you've isolated the device, and from there it's a driver update from the device's vendor, a different port or cable, or a peripheral that has worn out. If the crash happens with nothing extra attached, the suspect shifts to the platform's USB controller: update the chipset driver from your PC or motherboard vendor, and check whether a BIOS/UEFI update addresses a known USB issue for your board.

How to check RAM for memory errors

Faulty memory produces the most "random-looking" blue screens there are: different codes, no consistent trigger, crashes that no software change fixes. If you've worked the software branches and the crashes continue — or the code is a memory-flavored one like MEMORY_MANAGEMENT — RAM deserves a proper test before you go further.

The built-in tool is Windows Memory Diagnostic (search for it and choose to restart and test). It reboots the machine and checks the memory; the standard pass is quick but shallow, and the extended option is worth the extra time. A pass does not prove the RAM is perfect — a marginal module can slip through a single run — but a failure is a strong, actionable signal.

The definitive method is physical: with more than one module, test them one at a time (and in different slots), with the machine powered off and discharged before you touch anything. If the crashes follow one specific module, that module is replaced. And if you recently enabled an XMP/EXPO profile, test that first — an aggressive profile is a common cause of "bad RAM" that turns out to be a configuration problem, covered in the next article.

How to check for unstable RAM / XMP / EXPO settings

XMP (Intel) and EXPO (AMD) profiles make your memory run at its advertised speed instead of the conservative JEDEC defaults. They are usually fine — but they are also one of the most common causes of instability that masquerades as "bad RAM," because the memory is being asked to run beyond what it (or the board's memory controller) can reliably sustain. The crashes look exactly like a memory fault: random codes, MEMORY_MANAGEMENT, no software pattern.

The test is decisive and quick: enter the BIOS/UEFI at boot (typically Del or F2), disable the profile or load the default/optimized settings, save, and run the machine — including the workload that used to crash. If the crashes stop, the profile (or the board's handling of it) is the cause, and nothing about your RAM is defective.

From there your options: run at JEDEC defaults (slower but stable); try a lower profile if your BIOS offers stepped options; or update the BIOS/UEFI — memory compatibility is precisely the kind of thing vendors improve there. If you want the speed back, re-enable the profile and confirm stability with a long memory test rather than a day of casual use.

How to diagnose a faulty or unstable SSD / HDD

A degrading drive can blue-screen the system in several ways: the kernel fails to read data it needs (a page-fault code), the boot volume becomes unreadable at startup (INACCESSIBLE_BOOT_DEVICE), or a disk-controller error escalates into a crash. The fingerprint is a combination: random crashes plus long freezes, growing file-access errors, or — on a hard drive — unusual sounds. Any one of those deserves a health check; together, they're urgent.

The check is the drive's own health data (SMART), readable with the manufacturer's utility or reputable disk-health software. A status of "caution" or "failing" — or attributes like a rising reallocated-sector count — is a warning to act on, not a number to monitor over time.

The response to a genuinely failing drive is consistent: back up now, and plan to replace it. You don't repair a dying disk by running more checks on it. If the health data looks clean, the next storage check is file-system errors — chkdsk — because a corrupt file system can produce crash symptoms that look like hardware failure.

How to check your Windows drive for file-system errors

File-system errors — damage to the structures that record how files are laid out on a volume — can cause crashes, file-access failures, and boot problems. They arise from unclean shutdowns (which recurring crashes themselves cause), from a degrading disk, and occasionally from driver bugs, so the check is worth doing in the middle of a blue-screen investigation rather than only at the end.

The tool is chkdsk. From an administrator prompt, run it against your system drive:

chkdsk C: /f

Because the system volume is in use, chkdsk will schedule the check for the next reboot — agree, restart, and let it run. It can take a while, longer on a hard drive or a badly damaged volume, and the machine is unavailable while it works. If Windows won't start normally, the same tool is available from the Recovery Environment's command prompt.

Read the outcome: clean (no errors — the file system isn't your problem), or errors found and repaired (test the machine; if the crashes stop, that was a real contributor). If chkdsk repeatedly finds errors, or reports bad sectors, treat that as a hardware signal and check the drive's SMART health (diagnose your SSD/HDD) — the file system is usually the victim in that scenario, not the cause.

How to check CPU and GPU temperatures

Modern CPUs and GPUs protect themselves in two stages: they throttle (slow down) when they get hot, and they cut power when they get too hot — that second stage is what looks like a crash. "Too hot" is defined per component by its vendor (the maximum junction temperature), but a workable rule of thumb: a CPU sustained into the high 90s Celsius under load is in the range where throttling and instability become likely, and a GPU holding above its vendor's limit behaves the same way.

Measure rather than guess. A lightweight, reputable temperature monitor — your vendor's utility or a well-known third-party tool — shows CPU and GPU temperatures while you run the workload that used to crash. What you're looking for is the shape: temperatures climbing to a ceiling right before the crash, fan at full, is thermal. Temperatures that stay modest while the machine still crashes says heat is not the story, and you shouldn't spend time on it.

Interpret with the pattern: crashes that only come after long sessions or heavy load, with temperatures at the ceiling, go to overheating. Crashes under load with normal temperatures go to power or overclocking instead — the load correlation is real, but it isn't heat. This measurement is cheap and it eliminates a whole category of guessing.

How overheating can cause system crashes

Overheating reaches a blue screen through the protection mechanisms described above: throttling first, then a power cut at the thermal limit. Both produce crashes that look "random" while having a very non-random pattern — they come after the machine has been running a while, or under sustained load, and the fan is audible. That pattern is the diagnostic; measuring the temperatures confirms it.

The safe, common fixes are airflow. Clear dust from the vents and heatsinks (unplug and discharge the machine first; on a laptop, be deliberate rather than forceful). Unblock the vents — a soft surface, a wall, or a blanket changes a laptop's thermal behavior more than most people expect. Confirm the fans actually spin: a silent, still fan is a failed fan, and that's a part, not a setting.

Where it becomes a service job: dried-out thermal paste on a several-years-old machine that runs noticeably hotter than it did; a fan that rattles or has stopped; temperatures at the ceiling despite clean airflow. If the machine has been crashing hard for a while, a thermal service (cleaning and repaste) is cheap insurance before you test anything else — a hot machine gives you unreliable results on every other test in this hub.

How to check for CPU or GPU overclocking instability

An overclock — of the CPU, the memory (XMP/EXPO, covered separately), or the GPU — trades stability for performance, and the trade doesn't always announce itself on day one. Instability from an aggressive setting typically shows up as crashes under specific loads: a particular game, a render, a benchmark — precisely the conditions that push the component to the edge the setting promised. "It was fine for a month" doesn't clear a setting; instability can appear as drivers, temperatures, or workloads change.

The test is to remove the variable. In the BIOS/UEFI, load the optimized/default settings (this also disables the memory profile — so if XMP/EXPO is a suspect, it's covered by the same step). On the GPU side, remove any overclock or undervolt with the vendor's utility. Then run the workload that used to crash. If it holds, an overclock was your cause — and the decision is whether stock stability is acceptable, or whether you'll dial the setting back until it survives a long test rather than a short one.

Two things worth knowing. An undervolt is a stability setting too — GPU undervolts in particular are a known crash source, and they're easy to forget about because they're meant to be "safe." And stock settings are the control group that every other test in this hub assumes: if the machine is overclocked in some way, a crash is less diagnostic than it could be, because you're testing the system and the settings at once.

How to troubleshoot BSODs after installing new hardware

New hardware — a second RAM module, a GPU, an NVMe drive, a USB expansion card — gives you one of the cleanest "when did it start" answers possible: the crashes began the day you installed it. That doesn't prove the part is dead; it proves the change is the variable, which is exactly what you want in a diagnosis.

The test is removal: power off, unplug and discharge the system, take the new part out, and run the machine the way you used to. If the crashes stop, the part — or how it's installed or configured — is the cause. From there: reseat it firmly, try a different slot, check compatibility (memory speed and type against the board's support list), and update the chipset driver or BIOS/UEFI if the vendor lists a fix for the combination.

If removing the part changes nothing, it was a coincidence and the real cause was already present — back to the code and pattern evidence. One safety note: a failed part that shorts at the moment of connection is a real (if rare) way to damage a board, so if the machine starts misbehaving immediately around a fitted part — no POST, instant power-off — stop and get it looked at rather than retesting it repeatedly.

How to troubleshoot unstable power as a BSOD cause

Power problems produce crashes with a distinctive signature: they come under load, when the system is drawing real current — and sometimes there is no blue screen at all, just a power-off. If your "blue screens" are occasionally hard power-cuts, or the crashes correlate with your heaviest workloads, power deserves its own investigation. The companion log signal is a Kernel-Power 41 with no preceding BugCheck (Event Viewer).

Start cheap: a firmly seated power cable, a different wall outlet (failing outlets and overloaded strips do this), and on a laptop a known-good compatible adapter — a machine that's fine plugged in but crashes on battery points at the battery or the charging path. Then the harder question, the supply itself: an aged or under-rated PSU degrades gradually, fine at idle and marginal under load, and there is no reliable home test for that. The practical test is a known-good, correctly rated supply — and that swap is the one point in this whole hub where I'd strongly recommend a technician if you aren't already comfortable working on a system like that, because a PSU holds a charge and is the component that fails most consequentially.

If power is the confirmed cause, the fix is a replacement matched to the system's actual draw (a new GPU changes the math), not a workaround. A marginal supply "fixed" by reducing load will keep the problem — it just raises the threshold.

How to troubleshoot BSODs from BIOS / UEFI firmware issues

BIOS/UEFI firmware sits under everything: it configures memory, power delivery, and the USB and storage controllers, and a firmware bug can produce crashes that no Windows-side fix will touch. Two situations are relevant here. A known firmware defect — the vendor has released an update that fixes it — and an unstable configuration the firmware exposes, which the XMP/EXPO and overclocking articles cover separately.

As a stability test, "load optimized defaults" is the safest BIOS action there is: it resets the configuration to the vendor's baseline without changing the firmware itself. If the crashes stop after that, a configuration change was your cause. If the vendor's release notes for a BIOS update name your symptom (some do — "fixes system instability under load" is a real category of firmware fix), an update is worth doing, done properly: from the vendor's official page, following their procedure, with reliable power, and never interrupted.

How to troubleshoot BSODs after a Windows update

If the Reliability Monitor timeline shows your crashes clustering right after a Windows Update, the update is the prime suspect — either its own components, or (very commonly) a driver the update pushed. The good news: this is one of the most reversible causes there is, and the evidence is one glance at the timeline.

The path: Settings → Windows Update → Update history → Uninstall updates, remove the most recent one (a feature update, if one just landed, before the cumulative), reboot, and run the workload that used to crash. If the crashes are aggressive enough that you can't reach Settings, the same option exists in the Recovery Environment (Troubleshoot → Advanced options → Uninstall updates), and Safe Mode is your fallback for getting work done while you sort it out.

Two follow-ups. If the update had also pushed a driver, removing the update may not hold — roll the specific driver back (rollback) because the cumulative can return later and the driver is the actual fault. And don't solve this by turning Windows Update off: the fix is to remove or work around the bad change and let the rest of the updates keep flowing.

How to start Windows in Safe Mode

Safe Mode starts Windows with the minimum set of drivers and no third-party startup software. For blue-screen work it has two jobs. It's a working environment when normal mode is too unstable to use. And it's a diagnosis: if the machine is stable in Safe Mode, the cause is a third-party driver or piece of software — a big narrowing, because it rules out the deeper hardware possibilities for the moment.

To enter it: 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. If Windows isn't starting normally, the same screens appear from the automatic recovery loop — or you can trigger recovery by powering off at the Windows logo a couple of times.

Use it deliberately. Roll back a driver, uninstall a suspect program, create a restore point, or copy the Minidump folder to USB — then exit to normal mode and test. The discipline is one change at a time, with a normal-mode test after each, or you lose the ability to say which change fixed anything.

How to use System Restore after repeated BSODs

System Restore rolls the system state back to an earlier point — drivers, updates, installed programs — without touching personal files. For a recurring blue screen that started at a recognizable moment ("it began the day I updated X"), it's often faster and safer than unpicking each change by hand, because it removes all of them in one move.

To use it: Settings → System → Recovery → "Go back to an earlier point in time" (on some builds, search "Create a restore point" → System Protection → System Restore). Pick a point from before the crashes began and let it run; the machine reboots into the restored state. If Windows isn't booting normally, the same tool is in the Recovery Environment's Advanced options.

Know its edges. Restore points only exist if the feature was on — or if Windows made one before a significant change — and the window they cover is limited. And it fixes system state, not hardware: a bad module or a failing disk will crash the restored system just as happily. If no usable point exists, or the restore doesn't hold, the next rungs are removing the specific update (remove an update) or a repair install/reset (reset or reinstall).

How to remove a problematic Windows update

Removing a specific Windows Update is the surgical version of System Restore: you keep everything else and pull out the one change you suspect. It's the right first move when the timeline points at a particular update rather than a whole period, and it's more targeted than a restore point, which is convenient when no usable point exists.

In Settings → Windows Update → Update history → Uninstall updates, select the update — try the newest first, and a feature update before a cumulative if both are recent — remove it, reboot, and test the crashing workload. If normal mode is too unstable to reach Settings, the Recovery Environment offers the same operation under Troubleshoot → Advanced options → Uninstall updates.

Once it holds, two things. Check whether the update had also pushed a driver, because the driver can keep the fault alive after the update is gone (roll it back). And re-apply your pending updates over the following days so you're not sitting in a security gap — the goal is around the bad change, not away from updates as a class.

How to troubleshoot BSODs during Windows startup

A crash at boot — before you reach the desktop, or during the boot sequence itself — narrows the field considerably: the cause loads early, which means a boot-time driver, a storage problem, or a system component, and it rules out most of your everyday applications. The code matters here: INACCESSIBLE_BOOT_DEVICE is the classic "can't read the boot drive" signal, while a driver-flavored code (an IRQL variant) points at a driver that loads at boot.

Work it from the Recovery Environment, since normal mode may be unreachable. Startup Repair first — it's cheap and sometimes fixes the boot path. Then Safe Mode, if that gets you anywhere: it loads fewer drivers, so if Safe Mode boots, a boot-time driver is implicated and you can roll it back (rollback). Then System Restore to a point before the problem began. Alongside that, check what changed just before the first boot crash: an update, a new device, or a storage-mode change in the BIOS/UEFI — switching a drive between AHCI and RAID/NVMe modes is a classic INACCESSIBLE_BOOT_DEVICE cause with a trivial fix.

If the evidence points at the boot drive itself — disk errors, controller warnings in the logs, a drive making sounds — stop and treat it as storage: back up from the Recovery Environment or a live USB, then work the storage articles. A failing boot drive is the one startup scenario where speed matters for your data, not just your convenience.

How to troubleshoot BSODs after installing new software

Some software installs kernel-level components: a filter driver for disk or storage access, a network filter, a "virtual" device. A buggy one of those can blue-screen the whole system, and the fingerprint is a crash that started right after a particular program was installed — often a utility, an "optimizer," a game-boosting tool, or an aggressive antivirus.

The test is subtraction. Uninstall the most recently installed program first (Settings → Apps, or the vendor's uninstaller), reboot, and run the conditions that used to crash. If it holds, that was it; if not, step back one program at a time. A clean boot — disabling non-Microsoft startup items and services in groups — is the systematic version of the same test when there are many suspects, and Safe Mode is the environment to work in if normal mode has become unstable.

A caution that runs through this whole hub: the "PC cleaner" and "optimizer" category of software is itself a frequent crash cause, because it installs exactly the kind of kernel filter that can destabilize a system. If the crashes started after you installed one, removing it is the test — and a machine that's stable afterwards is the answer.

When you should consider resetting or reinstalling Windows

This is the last software rung, and the principle that governs it: a Reset or clean install fixes software. It cannot fix bad RAM, a failing disk, or a dying power supply — so you only get here after the evidence has pointed at the software layer, or at least failed to point at hardware, and you back up first regardless.

The ladder, in order of disruption: the targeted fix (the specific driver, update, or program) → System Restore to before the problem → a repair install (refreshes Windows in place, keeping files and most apps — the middle option people underuse) → Windows Reset (reinstall, keeping or removing files) → clean install from media (the most complete). Each rung is the right one when the one below has been tried and failed, or when the machine can't be brought up far enough to use it.

If the crashes continue after a clean install, that result is valuable: you've just proven the cause isn't in the software you had — it's hardware, firmware, or (rarely) the installation media itself. That's the point to bring your evidence — the codes, the dumps, the memory and disk test results — to a technician, because at that stage you're no longer troubleshooting a PC, you're testing components.

How to troubleshoot BSODs while gaming

A crash that only comes in games has a short list of likely causes, and the top of it is the graphics driver under load: the GPU working hard, its driver timing out (the code is VIDEO_TDR_FAILURE), or an overclock/undervolt and memory profile showing their instability exactly when the system is at its limit. The pattern is your friend — if it only happens in games, it's a load problem, and load problems are usually the GPU side, heat, or power.

Work in this order. The GPU driver first — a clean install from the vendor (the "clean install" option in the NVIDIA/AMD/Intel utilities exists precisely for this). Then temperatures under the game (check temperatures — a ceiling hit right at the crash is thermal, and goes to overheating). Then power (crashes reserved for the heaviest titles point at the supply — unstable power). Then stability settings: a GPU overclock or undervolt, and the memory profile (XMP/EXPO) — disable and retest.

Keep the distinction clear: a game that closes to the desktop is a game crash (driver settings, the game itself, its anti-cheat), not a blue screen. A blue screen in-game is the system stopping, and the evidence — the code, the dump — will name the GPU driver, the memory, or a kernel component. Follow it; the stop-code articles below cover each case directly.

How to troubleshoot BSODs when the PC is idle

A crash that happens when the PC is doing nothing is a different diagnostic problem from a load crash — and it has a classic cause: the machine waking from a power state. Sleep and hibernate resume is a moment when drivers re-initialize, and a driver that handles that badly will crash the system right as you start using it again, which feels like "it crashed while I wasn't doing anything."

Establish the actual pattern first: does it crash on resume, or after a long period at the desktop? On resume, it points at a power-state driver — graphics, network, and Wi-Fi are the common ones — so update or roll back the suspect (update, roll back) and test by deliberately sleeping and waking a few times. After a long idle, think background activity you didn't start: Windows Update applying, a scheduled task, an index rebuild — Reliability Monitor will show you what was running in those minutes.

Two more things to rule out. A power plan that's aggressive about sleep: hybrid sleep that's actually corrupting the hiberfile is a known, fixable cause, and disabling hybrid sleep is a quick, safe test. And the hardware suspects don't disappear just because the machine was idle — a marginal power supply can drop a system at low load, though it's less likely than the driver story. The log evidence (Event Viewer) still applies: a crash on resume with a named power-management driver is nearly a solved case.

How to fix the MEMORY_MANAGEMENT BSOD

MEMORY_MANAGEMENT means the kernel hit a problem while allocating or freeing memory. It's the most common "memory-flavored" code, and the important thing to hold about it: the memory in the name isn't always your RAM. A driver that references memory it shouldn't, or a disk that can't deliver data, can produce the same code — which is why the check order below goes by probability rather than by the name.

Work it in this order. First, a driver that recently changed: the dump will usually name one (identify the driver), and you update or roll it back. Second, the physical RAM: a memory test, per-module if you have several — and check XMP/EXPO before condemning the hardware. Third, corruption: SFC, then DISM. Fourth, the disk: SMART health and a file-system check, because a failing page-file location can produce memory-allocation failures.

The code's real value is in its combination with the other evidence. MEMORY_MANAGEMENT with a named third-party driver is a driver problem. MEMORY_MANAGEMENT with no named module, arriving randomly and surviving every software fix, is a memory or power problem until proven otherwise — which is why the RAM article is the one to keep open while working this code.

How to fix the IRQL_NOT_LESS_OR_EQUAL BSOD

IRQL_NOT_LESS_OR_EQUAL means a driver (or kernel component) tried to access memory at an interrupt level where that access isn't legal. In practice it's almost always a driver bug — the code describes a class of driver mistake, not a specific part — so the practical question isn't "what does this code mean" but "which driver."

Get the name, from the sources in descending order of convenience: the "What failed" line on the screen, the BugCheck entry in Event Viewer, and the dump analysis (minidumps), which is the most reliable of the three. With the name in hand, the path is the standard driver path: update from the vendor, roll back if an update preceded the crashes, or uninstall the owning software if it's a third-party component — anti-cheat, virtual drivers, and utilities of various kinds are regular offenders on this code.

If no module names itself, or the named module is an OS file, treat it as corruption first (SFC/DISM), then memory (a marginal module produces exactly this code with no useful module name — test it), then the usual load and pattern analysis. This code is frequent enough that a clean result from each of those checks is worth recording: it's how you earn the right to move on to hardware.

How to fix the PAGE_FAULT_IN_NONPAGED_AREA BSOD

PAGE_FAULT_IN_NONPAGED_AREA means a driver asked for a page of memory that wasn't there — non-paged memory being the portion the kernel requires to always be resident. It's a driver-family code, but its cause list is broader than most of its siblings: drivers, RAM, and the storage backing the memory (including the page file on a failing disk) all show up on this one.

The working order: the named module first (the same evidence sources as always — screen, Event Viewer, dump — per identify the driver). If none names itself, SFC and DISM to clear corruption. Then the memory test (RAM). Then the disk (SMART health and file-system check) — a disk dropping sectors under the page file is a real, if less common, cause. Security software and anti-cheat that install memory filters deserve a specific look on this code, because they're exactly the kind of component that touches non-paged memory.

Pattern note: this code with a consistent named module is a driver fix. This code arriving randomly, naming nothing, and surviving all the software checks is memory or storage wearing a driver's coat. The discipline is the same as every other code: one variable at a time, tested under the conditions that used to crash.

How to fix the SYSTEM_SERVICE_EXCEPTION BSOD

SYSTEM_SERVICE_EXCEPTION means a system process hit a condition the kernel couldn't recover from — a service or driver in the kernel's own layer misbehaved. It's one of the "broad" codes: the cause list spans drivers (storage and network in particular), system-file corruption, and, less often, software that hooks deeply into the system.

The practical order: the dump's named module — if there is one, it's usually a driver, and you update or roll it back. Then SFC then DISM: this is one of the codes that genuinely does get fixed by file repair, so it's worth doing early rather than last. Then System Restore, if the problem has a clear start date. And the usual memory and disk checks if the software layer comes back clean.

If the code persists through all of that, the remaining suspects are the hardware standard — unstable memory, a degrading disk, power under load — and the code's broadness is exactly why you don't fixate on it. It tells you the kernel layer is involved; the rest of the evidence (the pattern, the tests, the dump) tells you which part of it.

How to fix the CRITICAL_PROCESS_DIED BSOD

CRITICAL_PROCESS_DIED means a process the kernel depends on stopped running. The name sounds dramatic and the causes are more mundane: corruption in the system files (the most common software cause), a driver or third-party component that terminates or blocks a critical process, or — as with most codes — hardware underneath.

Start with the repair tools, because corruption is the leading software cause here: SFC, then DISM, then a test. If the crashes began after a change — an update, an install, a driver — work that change first instead: remove the update, roll back the driver, or uninstall the new software, in that order of likelihood. A System Restore to before the start date covers all three at once when a usable point exists.

If the software layer is clean, the code's remaining causes are the hardware standard: a memory test, disk health, and the load/power pattern analysis. One note: this code sometimes shows up on the tail end of a bigger problem — a disk that's failing and taking system processes down with it — so if it's accompanied by disk errors or long freezes, the storage articles take priority over the rest.

How to fix the DRIVER_IRQL_NOT_LESS_OR_EQUAL BSOD

DRIVER_IRQL_NOT_LESS_OR_EQUAL is the same class of bug as IRQL_NOT_LESS_OR_EQUAL — an illegal memory access at the wrong interrupt level — but the code explicitly tells you it happened in a driver's context. That's a useful narrowing: you're not hunting for a kernel bug, you're hunting for a specific driver, and the dump is almost always willing to name it.

So this article is really about the named module. The evidence sources, in descending convenience: the "What failed" line on the screen, the BugCheck entry in Event Viewer, and the dump analysis — on this code, WinDbg's output usually points at the module directly (WinDbg). With the name: a vendor update, a rollback if the crashes followed an update, or — frequently — uninstalling the software that owns the driver. Anti-cheat, virtual-disk, and security filter drivers are disproportionately represented on this code.

What separates this code from its sibling in practice: when no module names itself, the next step is more likely to be a filter-stack investigation than a memory test — a filter driver attached to the disk or network stack is the usual hiding place. If the dump analysis keeps pointing at a storage or network filter, that's your branch, and the networking and USB articles show how those stacks get implicated.

How to fix the VIDEO_TDR_FAILURE BSOD

VIDEO_TDR_FAILURE is the graphics-specific code: the GPU driver stopped responding within the time Windows allows, Windows attempted its TDR recovery (timeout, detect, reset), and the reset failed or repeated until the system crashed. TDR exists to recover from a hung GPU driver without a full blue screen — this code is that mechanism giving up, which is why it's such a clear signal to act on the GPU side.

The causes, in order of likelihood. The GPU driver itself: a clean install from the vendor is the first fix, and this code is one of the clearest signals that a driver reinstall is warranted (use the vendor installer's clean option — updating drivers safely). A GPU that's unstable at its current settings: an overclock or undervolt — remove it and retest (overclocking instability). Heat: the GPU at its ceiling right at the crash (temperatures, overheating). And, on the hardware side, a GPU that's degrading — which usually announces itself by the code getting more frequent over weeks rather than all at once.

If a clean driver install, stock settings, and good temperatures don't hold it, the remaining question is the card itself — and that's a test a technician can run (a known-good GPU swap) rather than a guess you make. One related case: a crash reserved to one specific game can be that game's demands hitting a driver edge — still a driver conversation first, and the anti-cheat stack in that game is a named suspect worth testing.

How to fix the WHEA_UNCORRECTABLE_ERROR BSOD

WHEA_UNCORRECTABLE_ERROR is different in kind from the codes above: it isn't Windows reporting a software failure, it's the platform — the CPU, memory controller, and firmware layer — reporting a hardware error the system couldn't correct. When you see it, the honest framing is that the machine is telling you its hardware had an uncorrectable event. That makes it the code with the highest "check your settings, then check your parts" ratio in this hub.

The usual suspects, in order. Unstable memory configuration first: an XMP/EXPO profile or an overclock pushing the memory past what the platform sustains is the single most common fixable cause, and the test is the same as everywhere — load BIOS defaults and see if the crashes stop (XMP/EXPO, overclocking). Then degraded memory: a test, per-module (RAM). Then, less commonly, a failing component (CPU, board) or marginal power delivery under load (power).

This is the code at which "professional" stops being a suggestion and starts being the likely outcome: if defaults, memory tests, and a stable power setup don't resolve it, the remaining diagnosis — which component — needs proper equipment. Bring the evidence: the code, the dumps, and what you've already ruled out ("XMP off, memory passed, defaults stable at idle") puts a technician in a completely different position from one starting from scratch.

How to fix the INACCESSIBLE_BOOT_DEVICE BSOD

INACCESSIBLE_BOOT_DEVICE means Windows started, reached the point where it needs to read the boot drive, and couldn't. It's a storage conversation: the drive, the path to it (the controller driver, the BIOS storage mode), or the system files on it. It usually lands you in the recovery loop rather than a readable desktop, which makes the order of operations matter more than usual.

Protect the data first: if the drive is the suspect — and it is failing until proven otherwise — back up from the Recovery Environment or a live USB before anything that stresses it. Then the checks, in order. Did a storage-mode change happen in the BIOS/UEFI (AHCI ↔ RAID/NVMe — a classic cause and the easiest fix)? Did an update or a storage driver change land right before (uninstall or roll back from the recovery environment — remove an update, roll back a driver)? Do the logs show disk-controller errors (a hardware signal)?

If the drive's SMART health says caution or failing, you're in storage territory: replace, not repair. If the drive is healthy and the mode and drivers check out, the remaining software branch is a repair install — it re-lays the system files that speak to the drive without touching your data, which is exactly the rung this code makes appropriate.

How to analyze Windows minidump files

Every blue screen that writes a dump leaves a file: small "minidump" files in C:\Windows\Minidump (and, if full dumps are enabled, a larger one at C:\Windows\MEMORY.DMP). A minidump is a snapshot of the system's memory at the moment of the crash — the stop code, the parameters, the state of the faulting driver — and it's the most precise evidence this hub deals with: the screen is a headline, and the dump is the full report.

You don't need special access to find them: open C:\Windows\Minidump (you may need to copy the folder elsewhere first, since permissions can be fiddly) and you'll see .dmp files named by date. Match the timestamp to your crash to pick the right one; if the folder is empty, your dump settings aren't capturing them — enabling dump collection fixes that. The files are small (a few megabytes) and safe to copy to USB for analysis on another machine.

What to look for when you open one (the tool is the next article): the BUGCHECK_CODE, which confirms you have the right crash; the faulting module — the .sys the analysis believes was involved; and the parameters, which for some codes name the specific memory address or object. One caveat to hold throughout: the named module is the suspect the analysis identified, not a verdict. Drivers get blamed because they're the layer that can do these things, and an innocent module can be at the scene. The dump narrows; the pattern and the tests decide.

How to use WinDbg for advanced BSOD analysis

The standard tool for reading a dump is Microsoft's Windows Debugger — WinDbg Preview, free from the Microsoft Store. It's a large tool for a small job, but the job it does — turning a .dmp file into "here's the code, here's the module, here's the call chain" — is exactly what the previous article builds toward, and it's the official analyzer for the files Windows writes.

The workflow: open the .dmp in WinDbg, and run the verbose analysis:

!analyze -v

Read three things from the output. The BUGCHECK_CODE and parameters — confirming the crash and, for several codes, naming the faulting driver directly. The FAULTING_MODULE line — the module the analysis implicates; cross-check it against the driver list in identify the driver. And the stack — the chain of calls that led to the crash, which matters most when the named module looks innocent and you want to see who called it; a third-party driver is frequently upstream of an OS file that took the fall.

Interpret with the discipline the whole hub uses. If the faulting module is a vendor driver, that's your update/rollback target. If it's an OS file, look at the callers in the stack before you chase the file itself. If it's nothing you recognize, the module name is a searchable string that usually identifies the owning software. And if the analysis gives you little of use, that's information too — it pushes you back to the pattern and the hardware tests (memory, disk, power), which is where the answer actually lives in a meaningful fraction of cases.

How to enable and verify crash dump collection in Windows

Everything in this advanced section assumes Windows is actually writing dumps, so it's worth a minute to confirm. The settings live in System Properties (search "Advanced system settings") → Advanced → Startup and Recovery → Settings, under "Writing debug information": choose at least Automatic memory dump or Small (64 KB) memory dump — the small/minidump option is enough for most analysis and writes its files to C:\Windows\Minidump.

The related setting on the same screen is "Automatically restart." For blue-screen work you want it off, so the next crash stays on screen and you can read the code and the "What failed" line directly (the same setting, with full steps, is in the keeps-restarting tutorial). The two settings work as a pair: one gives you the screen, the other gives you the file.

Verify before you need it: after changing anything, confirm the setting is the one you chose and that the C: drive has room (dumps are small, but a full dump is not). If the machine is so unstable you can't reach System Properties at all, the same settings are reachable from the Recovery Environment — that's the exception; the GUI path is the one to know.