PC Freezes or Crashes During Gaming but Does Not Restart: Drivers, RAM, Thermals, Storage, and Event Evidence

Start with the exact visible failure. A game that closes to the desktop, a game that stops responding while Windows remains usable, a brief display reset followed by desktop recovery, a full system hang, and a blue-screen Stop error are different diagnostic classes. An immediate restart or power-off belongs to the separate load-failure workflow, while display-only signal loss belongs to the monitor signal-loss workflow.

Record whether audio continues, whether the mouse or keyboard still responds, whether another display stays active, whether Windows eventually recovers, and whether a Stop code appears. This first split matters because it tells you whether to investigate one application, the graphics stack, broader system stability, or an operating-system bug check before replacing hardware.

Use one game or repeatable workload that reliably triggers the problem. Record the game version, graphics settings, display mode, GPU driver version, approximate time to failure, recent Windows or driver changes, and any user-applied CPU, GPU, or memory tuning. If telemetry is already available from supported vendor tools, note the relevant temperatures and clocks immediately before the failure without inventing a universal threshold.

Change one variable at a time. If the crash began after a driver update, a game patch, an XMP/EXPO change, an undervolt, or a hardware change, that timing is useful evidence but not proof of cause. A reproducible baseline gives later tests meaning; random combinations of driver changes, BIOS changes, and tuning changes erase that evidence.

Windows Error Reporting records application crashes and non-response conditions, and Event Viewer can expose Application Error and related events around the same time. Microsoft documents that faulting modules and exception information can help characterize a crash, but a module named in an event is not automatically the root cause. Correlate the event time, faulting application, module, exception data, and any adjacent driver or system events with the failure you actually observed.

If Windows shows a blue-screen Stop error, treat that as a separate bug-check path and preserve the Stop code or dump evidence. If the system hard-freezes so completely that Windows cannot write useful events, the absence of a clean log does not prove any component failed. Logs are strongest when several failures show the same pattern under the same conditions.

Windows Display Driver Model includes Timeout Detection and Recovery. Microsoft documents that when the graphics scheduler detects a GPU task that cannot complete or be preempted within the timeout, Windows can reset the graphics stack and restore the desktop. The user may see a brief flicker or an application may fail while the rest of Windows recovers.

A TDR-style recovery is evidence that the graphics path stopped responding; it does not by itself prove the GPU silicon is defective. Do not extend TDR registry timeouts as a generic fix. Instead, compare whether the problem follows one game, one driver version, one tuning state, or many unrelated 3D workloads before deciding which branch deserves deeper testing.

Use the graphics vendor’s supported installer and the game publisher’s normal repair or file-verification path where available. AMD and Intel both document supported clean-install options that reset or remove prior graphics-driver state before reinstalling the appropriate package. NVIDIA likewise provides driver update and rollback paths through its supported software. Prefer those vendor-supported paths over blanket third-party cleaner scripts as a first response.

If only one game crashes while other demanding 3D applications remain stable, investigate that title’s files, overlays, plug-ins, mods, anti-cheat, and known patch issues before generalizing the failure to the GPU. If many unrelated 3D applications fail in the same way, the scope has broadened and driver, tuning, thermal, memory, power, or hardware evidence becomes more relevant.

Memory profiles and user-applied CPU/GPU tuning change operating conditions. If the system is currently using XMP/EXPO, an overclock, an undervolt, custom GPU tuning, or altered power limits, returning only those user-applied settings to documented defaults is a useful isolation step. If stability returns at default settings, that shows the tuned state participates in the failure; it does not prove the RAM, CPU, GPU, or motherboard is defective.

Do not respond by inventing DRAM voltages, SOC voltages, GPU voltage offsets, timing values, or power limits. If the issue clearly tracks a memory profile, move to the dedicated RAM XMP/EXPO troubleshooting guide. If the machine stops completing POST after a memory change, use the no-POST workflow instead.

CPUs and GPUs use device-specific thermal management. A temperature reading is meaningful only relative to the exact device, sensor, workload, and manufacturer documentation. Look for repeatable evidence such as clocks reducing as a documented thermal limit is approached, a vendor-reported thermal condition, abnormal fan or pump behavior, or the failure appearing only after temperatures rise under sustained load.

Do not apply one universal CPU or GPU temperature cutoff to every system. A normal-looking GPU core temperature also does not rule out memory, hotspot, CPU, motherboard, storage, or case-airflow issues. If the crash follows a recent cooler or fan change, verify that installation using the exact hardware documentation rather than improvising a thermal fix inside this workflow.

A game can crash because its own files or cached data are damaged, and storage problems can surface as read failures, timeouts, or application-specific corruption. Start with the game platform’s supported file-verification or repair mechanism and review storage-related Windows or vendor diagnostics only when the timeline supports that branch. A slower-than-advertised SSD benchmark is not the same problem as a game crash.

Avoid destructive disk tests, repartitioning, formatting, or reinstalling Windows as an early diagnostic step. Preserve save data and other user files first. If the SSD disappears from firmware or Windows, move to the existing SSD detection workflow; if it merely benchmarks below a marketing number, use the NVMe performance workflow instead.

Use a bounded order: 1) classify the failure; 2) reproduce one workload and record versions, timing, recent changes, and telemetry; 3) correlate Windows Error Reporting and Event Viewer evidence; 4) test the supported graphics-driver and game-file path; 5) return user-applied tuning to documented defaults; 6) compare behavior across more than one workload; 7) investigate thermal or storage branches only when the observations support them; and 8) use known-good substitutions where practical before buying parts.

Route an actual restart, shutdown, or power loss to PC Restarts or Shuts Down Under Load. Route a display-only loss with an otherwise responsive PC to Monitor Goes Black or Loses Signal. Route a memory-profile-specific problem to RAM Running Slower Than Rated / XMP-EXPO Troubleshooting. A reproducible pattern that follows one component, slot, driver state, or workload class is stronger evidence than one event code or one crash.