BSOD after a Windows update, driver update, or new software: what to undo first

A post-update crash is a difference problem: the machine was behaving one way, then something changed, and now it behaves another way. Solving it means locating the difference, not guessing at it. The method runs in seven linked steps — change → timeline → evidence → hypothesis → reversible test → result → next decision — and each step produces the input the next one needs.

The step most people skip is the second one: the timeline. It's tempting to jump straight to "the last thing I did," but last changed is not the same as caused the crash. A change that landed three days before the first crash can be more likely than the one that landed an hour before, if the earlier change touched the exact subsystem the crash points at and the later one touched nothing relevant. Chronological proximity is one piece of evidence, not a verdict — and this whole guide is about weighing it against the rest.

Here's the loop in one picture: a change lands, you place it on a timeline, you gather the evidence that says whether it's connected to the crash, you promote the best-supported candidate to a hypothesis, you test it with a single reversible rollback, you read the result honestly, and you either confirm the cause or move to the next hypothesis. Nothing in that loop requires destructive recovery — which is exactly why it's safe to run before you consider a reset.

Tell the tool what you know changed and it'll show you the specific evidence to collect first. It's an organizing aid, not a diagnosis — it decides what to look at, not what's at fault. If nothing matches, choose "Multiple changes" or "Unknown"; both are common and both have a sensible first move.

A timeline is a dated list of everything that changed, ending at the first crash. Its job is to define a window: the machine was stable up to some point, then it wasn't. Every change that landed inside that window is a candidate; everything before the last known-good moment is, for now, out of scope. You're not trying to find the cause here — you're trying to find the field the cause lives in.

The anchor you're looking for is the last known-good state: the last moment the machine did the thing it now fails at, without a crash. "It booted to the desktop fine on Monday evening" is a usable anchor even if you can't name the exact minute, because it bounds the search. Once you have the anchor and the first crash, the interval between them is where you collect changes. A short interval is easier; a long one means you have more candidates to weigh, which is exactly why the next steps matter.

Here's a concrete shape so the abstraction becomes concrete. A Windows feature update installs Monday morning. A graphics driver updates Monday afternoon. A new hardware-monitoring utility is installed Tuesday. The first blue screen appears Wednesday during a game. The naive conclusion is "the Tuesday utility did it, it was last." But the timeline says something more interesting: the GPU driver changed right before a GPU-heavy workload started failing, and the utility doesn't touch graphics at all. The timeline doesn't prove the driver is guilty — but it correctly moves the driver ahead of the newest install, which is the entire point of doing this step.

One warning that pays off later: last changed is not caused. Proximity in time is correlation, and a crash that follows a change by an hour can still be caused by a change three days earlier that degrades something slowly (a marginal memory module that only fails under sustained load, a storage driver that corrupts a file that trips a later component). The timeline's value is that it makes you check the subsystem and the workload, not just the clock.

The single most common attribution error is treating "Windows Update" as one change when it's often several. A single update session can bump the operating system and push updated display, storage, network, audio, chipset, Bluetooth, and virtual-device drivers — all with dates that look identical in the update history. If you only know "an update happened on Tuesday," you can't yet tell whether the OS changed, a driver changed, or both, and those have different rollback paths.

Why this distinction matters is that the OS and its drivers fail in different shapes. A bad OS/quality update tends to affect things broadly and can be removed as a unit (uninstall the update, or — for a feature update, within its window — go back to the previous version). A bad driver is narrower: it usually shows up when its specific hardware is used, and it's rolled back per device, not per update. Conflating the two leads people to uninstall an OS update when the real culprit was one driver that happened to ship with it — a bigger, riskier reversal than the one actually needed.

So the goal of this step is to land in one of four boxes: the OS changed, a driver changed, both changed, or the timeline is too coarse to decide. You decide by comparing two independent date sources. Windows Update history dates the OS/quality change. Device Manager (per device) and the driver store date the driver packages. If the driver date is its own distinct moment, the driver is a separate change with its own evidence. If the driver date is identical to the update and you can't tell them apart, you're in the "both / can't decide" box — and the honest next move is the controlled sequencing in Category 8, not a guess.

A practical tell: driver updates delivered through Windows Update often appear as a "driver" entry in the update history and change the driver version in Device Manager. If you see a driver version jump with no separate driver entry, it likely came with the OS update. If you see a driver version jump with its own date or a vendor installer in the app list, that's a distinct change you can test on its own. Naming the box — OS, driver, both, or undecided — is what lets the next section rank the suspects instead of waffling.

"I installed an application" is a much weaker claim than "an application installed a kernel filter driver." A lot of software that looks app-level is actually system-level underneath: antivirus and security tools install kernel filter drivers and services; hardware utilities drop monitoring drivers and background services; some media and "booster" programs add virtual devices or network components. When one of those crashes the machine, the blue screen may be coming from the component the installer added, not the windowed program you click.

This matters for two reasons. First, it changes what to roll back: if a utility's background service is the suspect, closing the app won't stop the crash — you need to stop or remove the service or driver. Second, it changes how confident you can be: an app that only runs in user space is a different class of suspect than one that registers a kernel driver, because only the latter can directly cause many stop codes. Before you treat "the new app" as your hypothesis, spend a few minutes finding out which of these layers it actually touched.

You can investigate without guessing. In Device Manager, look for a new device or a driver whose install date matches the app — a freshly appearing "monitoring" or "filter" device is a strong signal. In the driver store (pnputil /enum-drivers), a new .inf/.sys dated to the install is the same signal from the other side. In the Services list, a service you don't recognize that started at the same time is another. If the installer only added an app and a shortcut and nothing at the driver/service layer, then it's a much less likely kernel-level suspect — which is useful information, not a dismissal.

Keep the layers distinct as you reason: application-level (a window you run), system service (a background process that starts with Windows), kernel-level component (a driver or filter that runs in the protected layer), and driver (the specific module that talks to hardware or a subsystem). A crash that only happens while the app is open points at the app layer; a crash that happens even with the app closed points at a service or driver it left behind. That distinction is what turns "I installed X" into a testable, correctly-scoped hypothesis.

Once you have a list of changes and a stop code, the next move is to rank them — not by how recent they are, but by how much independent evidence connects each one to this crash. The point is to produce an ordered list you can defend, so that when you roll something back you're testing your best-supported idea, not your most memorable one. A ranked list also tells you what to do next if the top choice fails: you already know the runner-up.

Seven factors do most of the ranking work. Proximity: how closely the change precedes the first crash — helpful, but the weakest factor on its own. Subsystem match: does the change touch the same part of the system the stop code points at? A GPU driver change alongside a VIDEO_TDR_FAILURE is a far stronger pairing than the same driver alongside a storage code. Repetition: does the same module or component show up across multiple crashes? One match is a lead; the same match every time is close to a diagnosis. Reliability Monitor: does it log a related failure near the change? Event Viewer: are there corroborating warning/error events (a driver failed to start, a device was disconnected) around the crash time? Safe Mode behavior: does the crash vanish in Safe Mode, which would implicate a third-party driver or service rather than the core OS? And workload specificity: does the crash only happen when a particular device is used, which pins the suspect to that device's driver?

The payoff of ranking is that it forces you to label your confidence honestly. A change can be strong (subsystem matches, the same module repeats, Safe Mode changes the behavior), moderate (it's recent and it touches a plausible area, but there's no corroboration), weak (it's just recent), or a likely coincidence (recent, but it touches nothing the crash implicates and nothing corroborates it). Treating a weak or coincidental change as if it were strong is how people waste hours uninstalling the wrong thing — and how they then conclude, wrongly, that "nothing is wrong." The ranking is what keeps that from happening.

Notice what ranking deliberately is not: it's not a rehash of the timeline. The timeline told you what changed and when. Ranking tells you which of those is most worth testing given the crash itself. If two changes are close in time but only one touches the failing subsystem, ranking resolves the tie the timeline couldn't.

The selection rule is: roll back the most plausible, reversible, evidence-supported change first. "Most plausible" comes from the ranking; "reversible" keeps you safe; "evidence-supported" keeps you honest. You're not trying to undo the most recent thing, the biggest thing, or the scariest thing — you're trying to run the experiment that, if it works, most cleanly identifies the cause and, if it doesn't, costs you the least.

The right first move depends on your scenario, and the scenarios do lead to different decisions. That's the whole reason to name your scenario before acting — because "roll back a change" is too vague to be useful until you know which change and why. The table below maps the common situations to a defensible first rollback. Where the evidence is genuinely insufficient, the honest answer is in the last row: don't guess, gather one more piece of evidence first.

Two guardrails keep this step from tipping into "undo everything." First, prefer the smallest reversal that tests the hypothesis: rolling back one driver is smaller than uninstalling an OS update, and uninstalling one app is smaller than a reset. Second, prefer the reversal that is easiest to undo the undo — a driver rollback can be re-applied, an app can be reinstalled, but a removed feature update is harder to get back. "Reversible" in the rule means both directions: you can reverse the change, and you can reverse the reversal.

This is the experimental-discipline section, and it's the one that separates a diagnosis from a cleanup. If you uninstall the new app, roll back the driver, and remove the Windows update all in the same sitting, you have run three experiments at once with one observation. If the crash stops, you don't know which of the three did it — so you've "fixed" the machine while learning nothing, and the next crash will start you from zero again. If the crash continues, you've changed three variables and can't tell whether one of them was on the right track. Either way, the multi-change reset destroys the one thing you're trying to produce: a cause.

So each test has a fixed shape: hypothesis → one intervention → reboot and retest → observe → record the result. Write the hypothesis down in one sentence ("the GPU driver update caused the VIDEO_TDR_FAILURE during gaming"), make exactly the one change that tests it, reboot, reproduce the original conditions, and write down what happened. "Retest" is not optional and it's not a single reboot — it's reproducing the conditions that produced the crash. A driver that only fails under load won't reveal itself at the desktop, so the retest has to be the game, the file copy, or whatever the original workload was.

What counts as a successful test is specific, and it's worth defining now because Category 7 builds on it. A test is successful if the original stop code stops recurring under the original conditions over a reasonable observation window — not merely if the machine boots once. A test is unsuccessful if the same crash returns under the same conditions. Everything in between (a different code, a lower frequency, a temporary lull) is a partial result, and it carries its own meaning, which is the next section. The discipline is to treat each of these as data about the hypothesis, not as a binary "fixed / not fixed" that you can only act on one way.

The concrete rollbacks look like this. These are the reversible, per-change moves — each one is a single variable, which is the whole point. (For the deeper, code-level reading of a crash, see the companion crash-dump guide; for reaching a stable state when the machine won't stay on, see the crash-loop and Safe Mode guide.)

The most under-used part of the method is reading the result correctly, because most people only have two buckets — "it worked" and "it didn't" — and the real results are more informative than that. A rollback's outcome is evidence about your hypothesis, and each outcome supports a different conclusion. Getting this right is what lets one experiment answer a question instead of just changing the machine.

Start with the two endpoints and their honest limits. If the BSOD disappears, that strengthens the hypothesis — the change and the crash are linked — but it does not by itself prove exclusive causation, because reverting a change can also stop a crash that was only partly caused by it (the change was a trigger on top of something else). If the BSOD continues unchanged, that weakens the hypothesis, but it does not automatically prove the change was irrelevant — the real cause might be a different change, or a component this one merely exposed. "Weaker" and "irrelevant" are not the same word, and conflating them is how a real cause gets written off too early.

The middle outcomes are where the real information is. A different BSOD appearing after a rollback often means you removed a trigger but uncovered the next layer — progress, not failure. A crash whose frequency drops but doesn't stop suggests the change contributed but didn't cause everything. A machine that's stable only temporarily (fine for an hour, then the original code returns) points at something cumulative — a slowly degrading module, a file that gets corrupted over time, thermal buildup — rather than a one-shot trigger. And a crash that changes under a different workload tells you the failure is workload-dependent, which sharpens which driver or component to suspect. Each of these is a distinct, actionable result, not noise.

The habit to build is to write the result next to the hypothesis before you do anything else. "Rolled back the GPU driver → VIDEO_TDR_FAILURE still appeared in the same game" is a complete, reusable observation. "Tried rolling stuff back and it's still doing it" is not. The first sentence is evidence you can carry into the next test; the second is a feeling.

The clean cases — one update, one driver, one app — are the easy part. Real machines usually change in pairs or chains: a Windows update followed by a GPU driver, an OS update followed by new security software, a driver update followed by a hardware utility, or a single installer that quietly adds a driver. When two changes are coupled, rolling back "one" can be ambiguous, and a naive single revert can leave the pair half-reverted — which is its own source of confusion. The goal here is to sequence the reverts so each step still tests a single, nameable variable.

The key insight is that interdependence usually has a direction, and the direction tells you the order. A Windows update and a driver that shipped with it are coupled: reverting just the driver while the new OS stays can leave a mismatch, and reverting just the OS while the new driver stays can do the same. In that case the honest unit of rollback is often both together, and your hypothesis should be phrased as "the update-and-driver pair," tested as one intervention. But a driver update that arrived after an OS update, from a separate vendor installer, is a distinct change even if it's close in time — and that one you can and should test on its own before touching the OS.

A controlled sequence handles the coupled cases without blind reversion. Take the "Windows update then GPU driver" example. Step one: roll back the driver only and retest — if the crash stops, the driver was the cause and you're done, having left the OS update in place (the smaller win). Step two: if the crash continues, roll back the OS update and retest — if it stops now, the OS change was the cause. Step three: if it still continues, revert both together and retest — if it stops only now, the two were genuinely coupled and neither alone was sufficient. Each step changes one thing, each observation is attributable, and you never end up in the "I undid a bunch of stuff and it works but I have no idea why" state.

For the "software that installs a driver" case, the interdependence is inside a single install: the app and its driver are one unit. The correct single intervention is to remove the unit completely — the app and the driver/service it registered — not just the app, because a leftover driver is precisely the thing that keeps crashing after "uninstalling." Checking the driver store and Services for what the installer left behind (as in Category 3) is what makes this a clean single test instead of a half-revert that mysteriously fails.

Chronology is the tool that fails most quietly, so it deserves its own section. A change can sit at the top of the timeline and still be innocent, and the real cause can be sitting further back — or not be a "change" at all. The three failure modes to recognize are trigger versus root cause versus coincidental timing, and they look identical on a timeline until you test them.

A trigger is a change that makes an existing weakness finally fail. A driver update doesn't "cause" bad RAM; it changes timing or memory pressure just enough that a marginal module that survived for months now errors on a given day. The timeline will point at the driver because the driver is the newest change, but rolling back the driver will only delay the crashes — the RAM was always the root cause. A coincidental case is even cleaner: an app installed the same afternoon an unrelated power supply started degrading. The two are close in time with no causal connection at all, and no amount of rollback of the app will help. The tell in both cases is that the rollback result is temporary or absent even though the change was perfectly timed.

So the timeline is a map of where to look, not a map of what's guilty — and the only way to separate a trigger from a root cause from a coincidence is the reversible test plus an honest reading of the result (Category 7). If rolling back the well-timed change gives you a temporary lull instead of a clean fix, that's your signal that you've found a trigger, and the root cause is deeper: usually hardware (a failing module, a degrading drive, a power or thermal limit) or a pre-existing component the update merely exposed. At that point the productive next step stops being "undo more changes" and starts being "test the hardware," which is the next section.

The practical habit is to never let a timeline do the concluding. Let it rank and let it focus, but require a test result before you call anything the cause. "The update was the last change, so the update is the cause" is the exact sentence this whole method exists to prevent. The timeline says "the update is a candidate"; only the reversible test and its result say "the update is the cause" — and even then, a temporary result should make you keep looking.

The least comfortable conclusion in change attribution is "the timeline doesn't support a rollback as the next experiment" — and it's the one that saves the most wasted effort. If your ranked list has no strongly-supported software change, or if every rollback you've tried has returned a temporary or absent result, then rolling back more changes is not the next best experiment. It's just more churn that changes variables you can't attribute. At that point the evidence is pointing somewhere else, and the productive move is to follow it.

Where the evidence usually points instead depends on what the result pattern and the stop code say. A crash that's workload- and thermal-dependent (only under load, machine runs hot) points at a cooling or power investigation, not an update. A crash with memory-area codes that no driver rollback fixes points at a proper memory test. A crash that's cumulative (stable for a while, then the same code returns) or a storage/file-system code points at disk health and file-system checks. A crash that only shows a repeating faulting module in the dump but resists every software rollback points at reading the crash evidence more carefully. And a machine that crashes even in Safe Mode, with no supported software change is a strong signal to escalate to hardware or professional support rather than keep rolling back software that isn't the cause.

The framing that keeps this from becoming a generic hardware article: you're not switching topics, you're following the same evidence to its correct destination. The question was always "what's the next best experiment?" For a while the answer was "roll back this change." When the rollback results stop supporting that, the honest answer becomes "the next best experiment is a memory test / a disk health check / a thermal check / a crash-dump read / a professional look." The method didn't change; the evidence did. These are the guides for exactly that next experiment: memory-related BSODs, storage and file-system BSODs, overheating and hardware instability, and reading the crash dumps.

One caution runs through all of it: "not a rollback" is not the same as "give up." It's a specific, evidence-based decision that the software-change hypothesis has been tested and not supported, so the search moves to the next most-supported hypothesis. You make that decision because of the timeline and the rollback results, not instead of them. That's the difference between a reasoned escalation and a frustrated one — and it's what makes the whole attribution method worth doing in the first place.

Everything above produces observations, and the single most useful thing you can do with them is write them down in a consistent packet. A packet is a short, dated record of the machine, the changes, the crash, and every test you've run with its result. It does two jobs: it keeps you from losing the thread across several reboots and sessions, and it lets anyone else — a friend, a forum, a technician — reason about the problem in five minutes instead of re-asking every question. The better the packet, the faster the next step is, whoever takes it.

The fields below are deliberately the ones this method actually uses: the machine identity, the timeline, the ranked suspects, and a log of each rollback with its result. Fill in what you know, mark what you don't as "unknown," and don't skip the rollback log — that log is where the real diagnosis lives, because it's the record of which hypotheses you tested and what each one told you. A packet with a full rollback log is far more valuable than a packet with a perfect timeline but no tests, because the tests are the evidence.

BSOD EVIDENCE PACKET
===================

Machine
  Device model / build:
  Windows version & build:
  BIOS / firmware version & date:

Timeline (most recent last)
  Last known-good state (what it did fine, when):
  Change 1 — type, what, date/time:
  Change 2 — type, what, date/time:
  Change 3 — type, what, date/time:
  First BSOD — date/time, what you were doing:
  Repeat BSODs — how often, when:

Crash
  Stop code:
  Bugcheck code (hex), if shown:
  Reported / faulting module, if available:
  Does it happen in Safe Mode? (yes / no / not tested)
  Workload it happens under (gaming, file copy, idle, random):

Ranked suspects (strongest first) and why
  1. (change) — evidence:
  2. (change) — evidence:
  3. (change) — evidence:

Rollback log (one per line)
  [date] Rolled back: ___  →  Result: ___  →  Next: ___
  [date] Rolled back: ___  →  Result: ___  →  Next: ___

Reliability Monitor / Event Viewer notes
  (any related failure or warning events, with times)

Decision
  What I'm testing next, and the one sentence of why:

The whole method in ten steps, in order. Work top to bottom; each step's output is the next step's input. Tick them as you go — your progress is saved in this browser.

This guide decides what to undo first. These cover the surrounding steps — reading the code the crash leaves behind, and the hardware tests for when the timeline stops supporting a rollback.