Worse After a GPU Driver or Game Update? How to Tell Which Update Caused It — Before-and-After Comparison, Rollback Tests & Settings Resets

2026-10-25 ｜ GPU Repair ｜ About 15 minutes ｜ HK GPU Fix Editorial Team

重點摘要

When a game gets worse after an update, the update that arrived last is not the update at fault. This guide sets out a before-and-after method: record a baseline, change one variable at a time, test a driver rollback and a clean install, reset the game's settings file, and check Windows updates and background software before attributing the regression.

The Short Answer First

A game that gets worse after an update has not necessarily been broken by that update. Updates arrive in bundles, land on the same day as other changes, and change more than one thing at once: a driver update changes the driver binary and resets control-panel profiles; a game update changes the executable and can change how the game's settings file is read; a Windows update can change display, audio, or scheduling behaviour underneath both. Blaming the most recent arrival is natural, but it is not a diagnosis. It is a starting suspicion that must survive testing.

The method in this article is deliberately boring, and that is its strength. Record what "good" looked like before the change. Change one variable at a time. Test each suspect in a way that can be reversed. Attribute the regression only when restoring one thing restores the previous behaviour and re-applying the change brings the symptom back. Anything short of that is a lead, and leads should be labelled as leads, because acting on a wrong attribution — rolling back a driver that was innocent, or reinstalling a game whose settings file was at fault — wastes time and can introduce new problems.

Two neighbouring topics are kept short here because they already have their own guides. Forced driver updates delivered through Windows Update are covered by article #189: this article cross-checks Windows Update history but does not rewrite that guide. First-run shader compilation stutter in modern games is covered by article #161: this article treats shader-cache rebuilding as one suspect among several and points past it rather than re-explaining it. The focus here is the comparison method itself: how to tell a driver regression from a game regression, a settings-file problem, and interference from other software.

Why Updates Change Behaviour in Several Ways at Once

A graphics driver is not a single file. It is a driver binary, a control-panel application with per-game profiles, a shader compiler, and a set of default settings. Installing a new driver can change any of those layers. A new driver binary can genuinely behave differently in a particular game. A profile reset can silently change anti-aliasing, V-Sync, frame-rate limiting, or power behaviour for that game. A shader-cache invalidation can cause temporary stutter while shaders rebuild. All three can follow a single driver update, and each points at a different fix: a binary regression calls for a different driver version, a profile problem calls for restoring the profile, and a cache problem calls for patience, not action.

A game update is similarly layered. It can change the rendering code, change the settings-file format so that an old settings file is read differently, change default settings for existing players, or change anti-cheat or overlay hooks. A settings file written by an older version of the game can carry values the new version interprets differently, or values the new version ignores while silently substituting its own defaults. The player sees "the same settings" on screen while the game behaves differently underneath, which is why a settings-file reset is a legitimate test even when nothing appears to have changed.

Windows Update adds a third layer that often lands on the same day. A Windows update can change the display driver model behaviour, audio drivers, power plans, or background services. A player who updates a driver and a game on the same day Windows installs an update has three suspects, not one, and the dates in update history are the only reliable way to separate them. Background software is a fourth layer: overlays, capture tools, monitoring tools, and security software hook into the graphics pipeline, and a driver or game update can break a hook that worked before without either the driver or the game being at fault.

Step One: Record a Baseline Before Any Update

The single most valuable habit in this whole article is also the simplest: before installing an update, record what good looks like. A baseline does not need to be elaborate. It needs to be specific enough that a later comparison is meaningful, and it needs to be written down, because memory of "it used to be smooth" is not evidence.

A useful baseline record contains the driver branch and install date, the game version, and the in-game settings that matter: display mode, resolution, refresh rate, V-Sync setting, frame-rate cap, and quality presets. Screenshots of the settings screens are the fastest form of this record, because they capture values the player might not think to write down. Alongside the settings, note a repeatable test scene — the same save point, the same map area, the same sequence of actions — and describe it qualitatively: smooth, occasional stutter in a particular spot, a crash at a particular moment, visual artefacts of a particular kind. Qualitative notes are enough, provided they are specific: "stutters when turning quickly in the town square" can be re-tested, while "feels worse" cannot.

If no baseline exists — the usual case, since most players only think about baselines after something breaks — reconstruct one from what is still knowable. The driver version before the update may be recorded in the driver's own history or in system logs. The game's previous version may be noted in a patch announcement or a community discussion. The settings file may carry a modification date that shows when it was last written. A reconstructed baseline is weaker than a recorded one, but it still constrains the investigation: it tells the tester which variables are known, which are guessed, and which are unknown, and that honesty prevents false confidence later.

Step Two: Describe the Symptom Precisely

Before changing anything, describe the symptom in terms that separate the suspects. The useful distinctions are timing, scope, and trigger. Timing: did the symptom begin immediately after the update, or after a delay? A symptom that begins on the first launch after an update points at the update; a symptom that begins days later points elsewhere. Scope: does it affect one game or several? A problem in one game only points at that game, its settings file, or its profile; a problem across several games points at the driver, Windows, or shared background software. Trigger: does it happen always, in one scene, at one setting, or after a long session? A symptom tied to one scene points at game content or shaders; a symptom tied to high settings points at resource behaviour; a symptom that grows over a session points at accumulation, such as a memory leak or heat.

Error messages and logs deserve the same precision. An error naming a driver file, a game file, or a specific module narrows the search considerably, and the exact wording should be recorded verbatim before searching for it. Windows Reliability Monitor shows a timeline of application failures, driver installations, and Windows updates on the same axis, which makes it the fastest tool for answering "what changed on the day the symptom began?" Event Viewer records the same events in more detail for a specific failure. Neither tool proves a cause, but both replace guessing about dates with dates.

Step Three: Change One Variable at a Time

The rule that makes every other step work is simple: change one thing, re-test in the same scene, record the result, and only then change the next thing. Changing the driver, the game settings, and the background software in one step may fix the problem, but it leaves the cause unknown, and an unknown cause cannot be prevented from recurring. Worse, a combined change can mask a real regression: a driver rollback plus a settings reset that together fix the symptom could be hiding a driver problem that will return the next time the settings are restored.

A practical test round looks like this. Pick the most likely suspect first, guided by timing and scope. Apply only that change. Run the same test scene for long enough to reproduce the symptom reliably — a symptom that appears only after extended play cannot be judged by a brief test. Record whether the symptom is gone, unchanged, or changed in character. Then either keep the change and move to the next suspect, or reverse it and try the next suspect. Reversal matters: a change that is kept without being tested in isolation becomes part of the new baseline by accident, and the next investigation starts from a contaminated baseline.

This discipline feels slow, and it is slower than changing everything at once. It is faster than the alternative, which is a cycle of reinstalls and rollbacks that never identifies the cause and therefore never ends.

Attribution Table: Reading the Pattern

The Driver Rollback Test, Done Properly

A rollback is a test, not a verdict, and it should be run like one. First, record the current driver version and branch so the change can be reversed. Then obtain the previous known-good driver from the graphics maker's official download page — the version that was installed when the game last behaved well, not simply any older version. Install it using the installer's clean-installation option, which removes leftover settings from the current installation. Restart, then run the same test scene.

If the symptom disappears on the previous driver, the driver change is implicated, but the test has not yet separated two sub-causes: the new driver binary itself, and the leftover profile or cache state that the clean install also removed. That separation is the next test: reinstall the current driver, again with the clean-installation option, and re-test. If the symptom stays gone on the current driver after a clean install, the cause was leftover state, not the new binary, and the player can stay current. If the symptom returns on the current driver even after a clean install, the new binary is the stronger suspect, and staying on the previous driver becomes a reasonable holding position while waiting for a newer release.

Two cautions belong here. First, a rollback is not a permanent solution to be applied without thought: staying on an old driver forgoes fixes and security improvements in later releases, so it should be revisited when a newer driver appears. Second, some driver branches serve different purposes — game-focused branches prioritize new-game support, while studio or professional branches prioritize stability — and switching branches is itself a variable change. If a branch switch is tested, it should be tested alone, with the same clean-install discipline, and recorded as a branch change rather than confused with a version change.

For a deeper cleanup, the Display Driver Uninstaller tool, run in Safe Mode, removes driver remnants more thoroughly than the installer's clean option. It is a stronger test, but also a more disruptive one: it removes profiles and settings entirely, and the machine must be restarted into normal mode and the driver reinstalled afterwards. Use it when the installer's clean option has not separated the suspects, not as the first step, and back up any custom profiles first. The deeper the cleanup, the more variables it changes at once, and the more carefully the result must be interpreted.

The Clean-Install Comparison

The clean-install comparison deserves its own emphasis because it is the test most often skipped. Many players, on finding that a rollback fixes a problem, conclude that the new driver is faulty and stop there. That conclusion may be wrong. The rollback also performed a clean install, which reset profiles, cleared caches, and removed leftover files. Any of those could have been the actual cause, with the new driver binary entirely innocent.

The comparison runs in three steps. Test the current driver as installed, with its existing profiles and caches. Test the previous driver with a clean install. Then test the current driver again with a clean install. The pattern of results separates the suspects: if only the previous driver passes, the new binary is implicated; if both clean installs pass, leftover state was the cause; if all three fail, the driver is probably not the cause at all, and the investigation should move to the game, Windows, or background software. Three installs take time, but they convert a guess into evidence, and evidence is what prevents the same problem from returning at the next update.

The Game Settings-File Reset

When a game update is the suspect, the settings file is the cheapest test available. Games store settings in a configuration file, sometimes in the game's installation folder and sometimes in a user documents or saved-games folder, depending on the game. The test is to back up that file, then let the game generate a fresh default file — by renaming the original, or by using the game's own reset option — and run the same test scene with default settings. If the symptom disappears, the old settings file, or a value inside it, is implicated. The player can then restore the backup and change settings one at a time to find the offending value, or rebuild the settings from defaults and keep the fresh file.

Backing up first is not optional. A settings file can contain key bindings, control customizations, and progress-adjacent preferences that are tedious to reconstruct, and a test that destroys them is a cost, not a diagnosis. The backup also makes the test reversible, which is the property that separates a test from a gamble. Note also that verifying game files through the game launcher is a different test from a settings reset: verification checks that the game's installed files match the expected set, which catches corruption, while a settings reset tests the player's own configuration. Both are worth running when a game update is suspected, but they test different suspects and should not be confused.

Shader Cache: The Suspect That Settles on Its Own

After a driver update, or a game update, previously compiled shaders may no longer match the new driver or game code, and the shader cache must be rebuilt. While rebuilding happens, the game can stutter: frames pause while a shader compiles, then run smoothly once the shader is cached. This is a transitional effect, not a regression, and it is the reason a driver should never be judged on the first session after an update. The full explanation of shader compilation stutter, including first-run compilation in modern games, is given in article #161; the point for this article is procedural. Give a changed system several sessions in the same scenes before concluding that the driver or game is at fault. If the stutter fades across sessions in the same scenes, the cache was the cause. If it persists unchanged across many sessions, or appears in scenes already visited repeatedly, the cache is not the explanation and the investigation should continue.

Clearing shader caches manually is sometimes suggested as a fix. It is a legitimate test — it forces a clean rebuild — but it should be understood as a reset that temporarily makes stutter worse before it makes it better, and it should be done for one cache at a time (driver cache or game cache) so the result can be attributed. Clearing every cache at once, together with a driver reinstall, is another combined change that destroys attribution.

Windows Update Cross-Check

When a symptom's start date coincides with a Windows update, the Windows update must be treated as a suspect in its own right. Check the update history for the exact dates: which Windows updates installed, and whether any of them delivered a display driver. Forced driver delivery through Windows Update has its own behaviour and its own guide, article #189, and this article does not repeat it; the cross-check here is narrower. If a Windows update and a driver update landed on the same day, the tester cannot attribute the symptom to either until one of them is isolated — for example, by testing the previous driver under the current Windows version, or by noting whether the symptom appeared before or after the Windows update completed.

Windows changes can also act indirectly. A Windows update can change the default power plan, re-enable a previously disabled background service, or update an audio driver that shares resources with the game. Those indirect effects are easy to miss because they do not announce themselves as graphics changes. The practical check is to compare the current Windows configuration against the baseline: power plan, background applications, and any driver Windows itself installed. If a Windows change is implicated, the remedy may be a settings change rather than a driver change, which is another reason the attribution step matters before acting.

Other Software: Overlays, Capture Tools, and Hooks

Overlays deserve suspicion whenever a symptom begins after a driver or game update but is confined to situations where an overlay is active. An overlay injects itself into the game's presentation path to draw its interface, and a driver or game change can break that injection without either the driver or the game being faulty. The test is to disable all overlays — the graphics maker's overlay, the game launcher's overlay, chat-application overlays, and capture-tool overlays — and re-test. If the symptom disappears, re-enable overlays one at a time until it returns. The overlay that brings it back is the suspect, and the fix may be an overlay update or a settings change in that application, not a driver change.

Capture and monitoring tools belong in the same category. A monitoring tool that reads graphics-card sensors, a capture tool that hooks presentation, and a streaming tool that encodes video all interact with the graphics pipeline, and any of them can misbehave after an update to the driver or game it hooks into. Test them the same way: disable the group, re-test, and re-enable one at a time. Security software is a rarer suspect but follows the same logic: if a security update landed on the same day as the driver or game update, it belongs on the suspect list until excluded by testing.

Keeping an Evidence Log

A short evidence log turns a frustrating afternoon into a repeatable investigation. Each entry needs a date, the change made, the test scene used, and the result in one line. An example sequence might read: driver updated, symptom appears in the town square scene; previous driver with clean install, symptom gone; current driver with clean install, symptom returns; conclusion, current driver binary implicated, holding on previous driver pending a newer release. That log is also what makes a later request for help effective: a support contact, a community discussion, or an inspection can work from the log instead of starting from "it got worse after an update".

The log also protects against a common trap: the moving baseline. Each test that is kept without being recorded changes the baseline silently, so that a later test compares against a state nobody remembers. Writing down each kept change — including profile resets, settings-file rebuilds, and cache clears — keeps the baseline explicit. When the investigation ends, the log becomes the record of what the machine now runs, which is exactly the baseline the next update's investigation will need.

When the Update Is Not the Cause

A disciplined investigation sometimes ends with the update exonerated. If the symptom survives driver rollbacks, clean installs, settings resets, cache rebuilds, Windows cross-checks, and overlay tests, the update was probably a coincidence that exposed or coincided with a different problem: cooling behaviour that changed with ambient conditions, a power supply under strain, or hardware degradation that reached a threshold at the same time. That conclusion is not a failure of the method; it is the method working, because it has excluded the software suspects and narrowed the field to hardware. At that point, load and temperature checks across several demanding games, and testing whether the symptom follows the graphics card or stays with the machine, become the relevant next steps, and an inspection is the sensible route if the symptom involves crashes, artefacts, or black screens that survive all software tests.

It is also possible for an update to be a partial cause: a new driver may expose a hardware weakness that an older driver masked, for example by managing power or clocks differently. In that case the rollback test will show the symptom disappearing on the old driver, which looks like a driver regression, but the underlying weakness remains and will return. The distinguishing evidence is whether the symptom reappears on the old driver under heavier load or longer sessions. A regression that is truly in the driver binary should be stable and reproducible on the new driver and absent on the old one under the same load; a weakness unmasked by the driver will eventually appear on both.

Frequently Asked Questions

Question: The game got worse right after a driver update. Is the driver definitely at fault?

Answer: Not yet. The update also reset profiles and invalidated shader caches, and a Windows update or game update may have landed the same day. Run the rollback test and then the clean-install comparison on the current driver. Only if the symptom returns on the current driver after a clean install, and stays gone on the previous driver, is the new driver binary the strong suspect.

Question: Should I roll back immediately, or try a clean install of the current driver first?

Answer: Try the clean install of the current driver first, because it is the cheaper test and it separates leftover-state problems from binary regressions. If the clean install fixes the problem, the player can stay current. Roll back only if the clean install does not help, or if the previous driver is needed as a comparison point.

Question: How long should I wait before judging a driver after an update?

Answer: Give it several sessions in the same scenes. Shader-cache rebuilding after a driver or game update causes temporary stutter that fades as shaders are rebuilt. Judging on the first session confuses that transitional effect with a regression. If stutter persists unchanged across many sessions in already-visited scenes, the cache is not the explanation.

Question: Only one game is affected. Does that rule out the driver?

Answer: It points away from the driver as a general cause, but not entirely: a driver profile is per game, and one game can interact with a new driver differently from others. Test that game's driver profile reset and the previous driver. If other games are unaffected and the profile reset does not help, the game's own update or its settings file becomes the stronger suspect.

Question: Will resetting the game's settings file delete my progress?

Answer: Settings files normally hold graphics, control, and interface preferences, not save progress, but the location and contents vary by game, so back up the file before resetting. The backup makes the test reversible and protects custom bindings. If the game stores progress in the same folder, back up that folder too before changing anything.

Question: What if the symptom began the same day as a Windows update and a driver update?

Answer: Treat both as suspects and isolate one. Check update history for exact dates and for whether Windows delivered a display driver. Test the previous driver under the current Windows version, or note whether the symptom appeared before the Windows update completed. Forced Windows driver delivery is covered separately in article #189.

Question: My overlays worked fine before the update. Why suspect them now?

Answer: Because an overlay hooks into the graphics pipeline, and a driver or game change can break that hook without either the driver or the game being faulty. Disable all overlays and re-test; if the symptom disappears, re-enable them one at a time. The overlay that brings the symptom back is the suspect, and its own update or settings may be the fix.

Question: I have tried every software test and the problem persists. What next?

Answer: The software suspects have been excluded, which narrows the field to hardware, cooling, or power behaviour that the update may have coincided with or unmasked. Note the full evidence log — what was tested, in what order, with what result — and bring the machine in for inspection, because that log lets an inspection start from evidence instead of from scratch.

Getting Help in Hong Kong

If the evidence log shows the symptom surviving driver rollbacks, clean installs, settings resets, cache rebuilds, Windows cross-checks, and overlay tests — or if it involves crashes, visual artefacts, or black screens that no software test removes — bring the machine in for inspection with the log. Note the driver versions tested, the settings-file test result, and the test scene used. HK GPU Fix is at Shek Mun, Dali Plaza, Room 1209. The phone number is 2186 8010 and WhatsApp is 6558 6806. There are no home visits and no Mong Kok shop. Inspection pricing follows the published three-tier range of HK$400 to HK$2,800, with a final quote after inspection.