BSOD Caused by Drivers: how to find, roll back, update, or remove the suspect

Every part advances the same five-stage process: suspect → evidence → confirm → change → verify. Parts 1–2 triage and build the suspect list, parts 3–5 are the evidence toolkit (dumps, WinDbg, Device Manager), parts 6–9 are the four safe ways to change a driver, parts 10–11 cover recovery and the one tool that can force a confirmation, and part 12 handles the uncomfortable case: when the driver was never the cause.

Before you touch a single driver, ask whether the pattern even looks driver-shaped. It matters because the fix for a driver crash — a rollback or an update — is cheap and reversible, while the fixes for failing RAM or a thermal problem are not. A week of driver-hunting on a machine with bad memory is a week lost, and the reverse is just as true.

What a driver-shaped crash looks like. The same stop code appearing across several crashes, with the same driver filename in each dump. Crashes that started immediately after a driver update, a GPU driver install, a new device, or a Windows update that shipped drivers. Crashes that follow a workload — a GPU code when gaming, a network code when streaming. And, very usefully, a machine that stays stable in Safe Mode, because most third-party drivers don't load there (Safe Mode and the recovery paths are covered properly in Part 10).

What doesn't look driver-shaped. Random crashes with a different module named every time; memory-style codes with clean dumps; crashes that only happen under heavy load while the machine runs hot; crashes that began after a BIOS or UEFI change; and crashes that started with nothing changed at all, which usually means something is degrading — RAM, power supply, disk, or thermal paste.

Suspect versus confirmed. A driver being mentioned in a crash report makes it a suspect. Confirmation requires either behavior — the crashes stop when the driver is rolled back or removed, and (if you're thorough) return when it's restored — or strong corroborating evidence: the same module across multiple dumps, a timeline that matches a driver change, and clean results on the non-driver tests. Until you have one of those, treat the driver as a lead and keep the other causes in play. The table below is your quick triage reference.

You now have a hunch. This part turns it into a list. Five sources of information exist, each tells you something different, and used together they produce a short suspect list you can act on — usually one or two drivers, in order of confidence.

The sources, in order of usefulness. The stop code on screen tells you the type of fault but, on modern Windows, rarely names anything. The minidump (explained in Part 3) names the module that was in the kernel when the fault was recorded — your primary lead. Event Viewer's System log shows driver install and failure events plus hardware (PnP) events with timestamps — useful for proving when a driver changed or a device was added. Reliability Monitor gives you the crash history with stop codes and dates, which is how you build the timeline. Device Manager shows the current driver version, date, and provider for any device — the "what's installed now" reference (read in Part 5).

Why correlation isn't causation. If one dump names ndis.sys and nothing else lines up, that's a low-weight clue. If the same module appears in five dumps with a driver update dated the day the crashes started, that's a high-weight one. The pattern across multiple crashes always beats any single report, and the timeline is what converts a pattern into a case.

The evidence workflow, in order:

1. Record the crash: stop code, QR code, and any filename shown on the blue screen, plus what you were doing.
2. Save the dumps: copy the most recent minidumps out of C:\Windows\Minidump to a folder you control, named by date.
3. Look for the repeat: compare the dumps — is the same module named in several of them?
4. Build the timeline: from Device Manager driver dates and the update history, list every driver, device, and BIOS change in the last few weeks.
5. Check Event Viewer around each crash time for driver-failure or PnP events.
6. Write the suspect list: one to three drivers, ranked. If you can't name one, that's a valid result — go to Part 3 for dump-based identification or Part 12 for non-driver causes.

A minidump is the raw material of every diagnosis in this series, so it deserves a part of its own. When Windows stops, it writes a snapshot of the crash: the bugcheck code and its parameters, the modules that were loaded, and a slice of the kernel call stack. On most systems these files are small (a few megabytes), one per crash, stored in C:\Windows\Minidump. If full dumps are enabled there's also a single MEMORY.DMP in C:\Windows, and non-fatal warnings may appear as Live Kernel reports in C:\Windows\LiveKernelReports.

What you're actually extracting. Four things: the bugcheck code (the stop code in hex — it should match what you saw on screen), the parameters (extra values, often pointers — rarely human-readable, but the fact that they differ between crashes is itself information), the faulting module (what the analysis points at, often under "Probably caused by"), and the stack order (what called what, which separates a driver acting from a driver standing in the blast radius).

The limitations, stated plainly. Automated analysis is a best guess. The named module can be where the fault was detected, not where it originated — a driver or a memory error can corrupt a kernel structure and a completely different component trips over it. A single dump is a snapshot, not a verdict. This is why Part 2 insisted on patterns across dumps, and why nothing in this series treats one analysis line as proof.

Practically: you don't need to become a crash analyst. You need a shortlist and a consistency score. List the dumps, open the newest, note the module, repeat, compare. Start here by listing what you have:

WinDbg is Microsoft's debugger; for this job you only need its crash-dump mode. Install it from the Windows SDK (or use WinDbg Preview), then open your saved minidump with File → Open Crash Dump. That's the entire setup — no configuration, no running services, no risk to your system. You're reading a file, not touching a machine.

The basic workflow. Run the full analysis first — it does most of the reading for you. Then list the loaded modules to see the suspect in context, pull the details of one module to cross-check its version and path against Device Manager, and inspect the stack to see who called whom. If you want to inspect a driver object directly, the driver-object command takes the address shown in the module or stack output.

Reading the output without over-trusting it. The line everyone screenshots — "Probably caused by : x.sys" — is the analyzer's best guess, and it's often right, but "often" is the operative word. Check two things. First, whose file is it? A vendor path (GPU, NIC, storage maker) is a real suspect; a Windows system file being named usually means the corruption came from elsewhere and the system file was where it landed. Second, what called it? A stack full of that module's own frames is stronger evidence than a single frame sitting under kernel code. Then do the thing Part 2 demands: run the same reading on your other dumps and see if the picture holds.

Device Manager won't read your crash history — but it is the map that turns a dump's filename into a real device with a version, a date, and a provider. Open it (right-click Start → Device Manager), find the device category that matches your suspect, and right-click the device → Properties. Everything in this part lives in that Properties dialog.

The five fields that matter. The status icon: a yellow warning means Windows can't run the device normally, and the Device Status text explains why — a generic "device not working" (code 43) frequently travels with driver crashes. The Driver tab gives the provider, date, and version — the date is your timeline anchor from Part 2. The Driver Details tab lists the actual files that make up the driver; these .sys names are exactly what appears in a minidump, which makes this tab the join key between your evidence and your hardware. And the Hardware IDs (under Details → Hardware Ids) are the device's identity codes — what you paste into a vendor's support site to get the exact right driver.

Three sources, three different packages. The same piece of hardware can be driven by a Windows Update package (generic, broadly tested, applied automatically — a very common "it changed and now it crashes" culprit), your PC maker's OEM package (tuned for the machine, sometimes years out of date), or the component maker's package (GPU and NIC vendors: newest features, sometimes newest bugs). The provider field tells you which one installed your current driver, which tells you where to get a known-good version and how to explain a crash that followed an "automatic" change.

The join, concretely: your dump says nvlddmkm.sys. Open Device Manager → Display adapters → Properties → Driver Details, and you'll find that file listed. That device — with its provider, date, and version — is now your named suspect, and Parts 6–9 are what you do with it.

Rollback is the first fix to reach for, because it's the cheapest reversible test you have: it restores the exact driver package that was running before the change, and if the crashes were caused by the update, they stop. It's the right move when crashes began right after a driver update, a stable previous version exists, and the old version demonstrably wasn't crashing.

Before you roll back, confirm the version story. In Device Manager → device → Driver tab, note the current version and date. Your timeline from Part 2 should show the crash window starting at or after that date — if the "current" driver predates the crashes, rolling back it fixes nothing, and you want the update path (Part 7) instead.

1. Open the suspect device in Device Manager → Properties → Driver tab.
2. Click Roll Back Driver. If it's enabled, Windows will name the previous version — confirm that's the one that was stable, then confirm the rollback.
3. Restart so the old package is fully in effect.
4. Verify in Device Manager that the version/date now match the previous package.
5. Run the workload that used to crash — not for five minutes, but over a day or two of normal use.

When Roll Back Driver is greyed out. The previous version is gone from the driver store — the device was reinstalled, the old package was cleaned up, or the driver was first installed manually (there is no "previous" to go back to). Your alternatives: download the specific older version from the vendor and install it deliberately (Part 7's sourcing rules apply), or list the packages in the store to see what's actually available before deciding.

Verifying the result. A rollback "works" only if the crash stops — same stop code not returning over real use. If the crashes continue on the old version, one of two things is true: the old version has the same bug (move to Part 7 or Part 8), or the driver wasn't the cause (move to Part 12). Either way, you've learned something concrete, which is the point.

Update is the right move when the current version is known to be bad — the vendor's release notes name the very crash you're seeing, or your dumps and timeline point at a version with documented defects — and a newer stable version exists. The difference between a safe update and a new problem is almost entirely in where the package comes from and what you do before and after.

Where drivers should come from. The component maker, first: GPU drivers from NVIDIA, AMD, or Intel; network and storage drivers from the chip or device vendor's support pages. Your PC maker's support site, second — especially on laptops and prebuilt desktops, where the OEM package is tuned (and where "Windows Update installed a driver" often means the OEM's own package was replaced by a generic one). Windows Update third — including its "Optional updates" section, where driver updates sometimes sit — useful, but it's a broadcast channel: you get what's been cleared for everyone, not what's best for your exact board.

"Newest" is not the same as "right for this system." Vendor betas and same-week releases are where crash-prone drivers most often come from. A version that's a year old but stable on your hardware generation can be the correct choice, and vendor release notes that explicitly mention BSOD or crash fixes are the strongest signal to move to a specific version. Match the package to your exact model — the Hardware IDs from Part 5 or the model label on the machine — before you install anything.

1. Create a restore point (Settings → System → Recovery → System protect) so the update is reversible.
2. Download the specific package from a verified source, matched to your exact model.
3. Install it, then restart.
4. Verify in Device Manager: new version and date present, no warning icon, Driver Details listing the expected files.
5. Run the crash workload over real use. If it still crashes, this version isn't the fix — roll back (Part 6) if possible, or move to removal (Part 8), and revisit the diagnosis (Part 12).

Removal is for when the driver is beyond a version change: corrupt beyond update or rollback, attached to a device you're replacing, or one that misbehaves so early in boot that only Safe Mode (covered in Part 10) can touch it. It's also the first half of a clean reinstall (Part 9). Work down this ladder in order — each rung is more thorough and more consequential than the last.

1. Uninstall from Device Manager: right-click the device → Uninstall device → tick "Delete the driver software for this device" → confirm. This removes the driver for that device and, with the tick, its package.
2. Check the store for leftovers. If the package is shared with other devices or lingers, list the installed packages and look the specific one up by name before acting — never delete by guessing at an ID number.
3. Repeat from Safe Mode if the driver resists. A driver that only misbehaves while running can usually be removed cleanly once the system is booted without it.
4. Use the vendor's clean-removal path for GPU drivers where one exists (typically: boot to Safe Mode, then run the vendor's installer or cleaner). These drivers leave the most state behind.

After removal, expect a warning icon. The device now has no driver — that's the point, and it's temporary. If the crashes stop while the device is disabled, you've just run the cleanest confirmation test available: the cause and the cure are the same component. Reinstall properly in Part 9, or leave it removed if the device is being replaced.

A clean reinstall is for three situations: the driver state is corrupt (updates and rollbacks have failed), you just removed a driver (Part 8), or a new device needs its first proper driver. "Clean" means old state is gone, exactly one known package is installed, and the result is verified — not merely "installed," which is a weaker claim than it sounds.

1. Remove what's there (Part 8, step 1) if a driver is present, then restart so nothing holds the old state.
2. Download the correct package — Part 7's rules: verified source, exact model match.
3. Install it and restart again.
4. Verify in Device Manager: no warning icon, the expected version and date, and Driver Details listing the files you'd expect for that package.
5. Run the workload that used to crash — over a day of real use, not a smoke test.

Verify deeply, using your dumps. You saved minidumps from the crashing era in Part 2 — keep that folder. If a new crash happens after the reinstall, open the new dump and compare: is the old module gone, replaced, or still there? "Gone" means the reinstall addressed the cause. "Still there, same stack" means the package you installed has the same defect — go get a different version. "Different module" means the original suspect was probably a symptom (Part 12).

Know the four actions cold. They're similar words with very different effects, and choosing between them is most of this part of the series:

This is the highest-stress version of the problem: a bad driver (often one Windows Update installed) now crashes the machine on every boot, usually just as the desktop appears. The good news is structural — most third-party drivers don't load in Safe Mode, which is exactly the lever you need. This part also defines the recovery paths other parts referenced.

Getting to the recovery environment. If Windows can't start three times in a row, it enters the Windows Recovery Environment (WRE) automatically. To force it: interrupt a startup by holding the power button until the machine is off, then turn it on and interrupt again — two or three times — or, on a machine that still boots, use Settings → Recovery → Advanced startup. From WRE: Troubleshoot → Advanced options → Startup Settings → Restart, then choose Safe Mode (or Safe Mode with Networking if you need to download a driver).

The paths, in order. First, in Safe Mode: roll back or uninstall the suspect driver using Parts 6 and 8 — for the classic "update installed a bad driver" case, this alone breaks the loop. Second, if the trigger was a Windows update that shipped the driver: uninstall that update from the recovery options (or from Settings once you're in Safe Mode). Third, if you have a restore point from before the change: System Restore reverts system and driver state to that point in one step. Fourth, Startup Repair can attempt automatic boot fixes, though for driver problems it's the least targeted option.

If Safe Mode also crashes, the cause sits below the normal driver layer — kernel, storage controller, firmware, or RAM. At that point the driver toolkit has been exhausted: back up what you can from the recovery environment and move to the deeper cluster pages — memory-related BSODs, storage problems, and the final recovery checklist.

When to stop. Repeated failed recovery attempts, data at risk, or no recovery environment at all are the three signs that the cost of continuing exceeds the cost of a repair install (which keeps your files) or professional help. Stopping there is a sound engineering decision, not a failure — say so to yourself out loud, because that's the moment people usually start doing dangerous things to a machine.

Driver Verifier is the one tool in this series that can force a confirmation. It runs Windows' standard verification checks against a driver while the system runs — monitoring for illegal memory access, wrong interrupt levels, and the other things drivers are not allowed to do. A driver with a real bug will usually crash on its own while verified, and the resulting dump typically pins the blame unambiguously. That's the benefit. It's also why this part exists as a warning as much as an instruction.

Why it's dangerous by design. Verification is stricter than normal operation. Some drivers that "mostly work" will crash under verification even though they'd run fine unverified — the crash is real evidence of a coding fault, but on an already-unstable machine it can also be the difference between "annoying BSODs" and "boot loop." You run Verifier deliberately, with a narrow target, on a machine you know how to recover. Enabling it for all drivers on an unstable system is how a single suspect becomes a dozen crashes.

The conservative procedure:

1. Narrow the suspect first using Parts 1–5. Verifier without a shortlist is just a crash generator.
2. Set up your exit before entry: a restore point, and a confirmed, tested path to Safe Mode or the recovery environment. If you can't reach either on demand, don't run Verifier.
3. Enable it on one or two specific drivers only (run verifier.exe from the Start menu, or verifier from a prompt). Use the standard checks; leave the additional/stress options alone unless you're experienced and isolated.
4. Reproduce the normal workload — or simply use the machine as usual. A verified buggy driver typically crashes on its own within a short while.
5. If it crashes: the dump will usually name the verified driver with unusual clarity. That's your confirmation — the strongest evidence type in this series. Analyze it (Part 4), then fix the driver (Parts 6–9).
6. Disable Verifier immediately afterwards — even if it didn't crash. Verified-but-harmless drivers still run under extra scrutiny for no reason.

If Verifier itself causes a loop: boot to Safe Mode (verification can often be cleared from there) and run the disable command above; if you can't reach Safe Mode, use the recovery environment or a different Startup Settings option to get a shell and clear it there. Because of exactly this failure mode, the rule stands: if you're not comfortable reaching Safe Mode on demand, skip Verifier entirely — the dump-plus-timeline method from Parts 2–5 gets you most of the way without the risk.

The uncomfortable truth that makes the whole series honest: a module named in a dump can be innocent. Failing RAM corrupts whatever kernel memory it lands on — sometimes that's a driver's structures, so the driver shows up in the report. Failing storage can corrupt driver state on disk. Heat and unstable undervolts flip bits that look exactly like driver bugs to an analyzer. If your "driver fix" didn't hold, or the evidence never fully lined up in the first place, this part is where you go.

The alternative causes and their fingerprints. RAM: a different module in every dump, memory tests that fail — see memory-related BSODs. Storage: disk and file-system codes, a slowly degrading drive, SMART warnings — see storage problems. Unstable overclock or undervolt: crashes only under load, fixed by resetting the BIOS to defaults — the single most satisfying "fix" in all of troubleshooting when it's the cause. Heat: high sustained temperatures and throttling, crashes under sustained load — see overheating and instability. Firmware: crashes that began after a BIOS/UEFI update; a firmware rollback, not a driver change, is the fix. Corrupted Windows: system-file modules in dumps, SFC/DISM finding real problems — see system-file repair. Power: random crashes, often under load, no consistent module — a weak or failing supply. Software conflicts: antivirus, overlays, and utilities that hook into the kernel.

Clean boot, for the software-conflict case. If Safe Mode is stable but normal mode isn't, and the dump evidence is thin, a clean boot separates Windows from everything you installed. Open System Configuration, hide all Microsoft services, disable the rest, and disable startup items from Task Manager — then re-test. If the crashes stop, re-enable services in halves to find the offender. If they continue, software conflict is off the table and you're back in driver/hardware territory with a shorter list.

The decision rule, in one line. "A driver was mentioned" is a hypothesis. Evidence for it is: reproducibility (crashes when the driver works), timeline (crashes started at the driver change), exclusion (the non-driver tests come back clean), and confirmation (the crash stops when the driver changes — or Driver Verifier pins it). Count how many of the four you actually have. Two or fewer? Keep testing. Don't replace hardware, and don't reinstall Windows, on the strength of a rumor.

The whole series compressed into a route. Answer the questions and you'll land on the part — or the neighboring guide — that matches your evidence. Remember what the tree is not: it's a way to stop guessing, not a machine that pronounces guilt. A driver appearing in a crash report is treated here as a lead, exactly as it is in every part above.

The full workflow as tickable items — from first crash to verified fix. Your progress is saved in this browser, so you can work through it across several reboots, which is about how long a real driver investigation takes.

Where this series connects to the rest of the library — the general BSOD map, the non-driver causes Part 12 points at, and the wider hardware library.