Troubleshooting guide

PC Restarts or Shuts Down Under Load: Temperatures, PSU, RAM Stability, Event Logs, and Power Troubleshooting

Diagnose a PC that reaches Windows but restarts, powers off, freezes, or crashes under CPU/GPU load by separating thermals, tuning, power delivery, memory stability, and event-log evidence.

On this page
  1. First classify the failure instead of calling every crash a power problem
  2. Return user-applied CPU, GPU, and memory tuning to documented defaults before deeper diagnosis
  3. Treat temperature and throttling as evidence, not as one universal shutdown number
  4. Verify cooling behavior with the system powered down before assuming the cooler is defective
  5. Inspect the external and low-voltage power path without treating a protection trip as a PSU verdict
  6. Change the workload one dimension at a time to see what actually triggers the failure
  7. Keep RAM profile instability as a separate branch instead of retuning memory here
  8. Use Windows Event ID 41 to confirm an unclean restart, not to diagnose a failed PSU
  9. WHEA and driver or application evidence can narrow the branch, but still need context
  10. Use a bounded evidence-first order and escalate only when one branch has supporting observations

First classify the failure instead of calling every crash a power problem

Start by recording what the machine actually does. An application closing while Windows stays usable, a blue-screen Stop error, a hard freeze, an automatic restart, and an abrupt loss of power are different observations. A PC that reaches the operating system and then fails during load is also a different troubleshooting state from a machine that cannot complete POST.

Note the workload, approximate time to failure, whether the display goes black before the system restarts, whether fans and lighting lose power, whether Windows shows a Stop error, and whether the same behavior appears outside one application. Do not infer a failed PSU, GPU, CPU, or RAM module from the symptom alone. The purpose of the next steps is to find which conditions reproduce the failure and which do not.

Return user-applied CPU, GPU, and memory tuning to documented defaults before deeper diagnosis

Overclocks, undervolts, raised power limits, custom GPU tuning, PBO-style settings, and XMP/EXPO profiles can all change the stability boundary. AMD documents default/reset controls for Ryzen Master and Radeon performance tuning, while Intel documents restoring XTU/BIOS defaults. If the problem started after tuning, or the current tuning state is uncertain, establish a stock/default baseline before blaming hardware.

Change only the settings you intentionally modified and use the exact platform/vendor reset procedure. Do not invent replacement voltages, timings, power limits, or frequency offsets as a generic repair. If returning memory to default operation resolves the restart, use the existing RAM-speed/XMP/EXPO troubleshooting workflow to investigate that profile separately rather than repeating memory tuning here.

Treat temperature and throttling as evidence, not as one universal shutdown number

Modern processors and GPUs have thermal-management mechanisms. Intel describes processor throttling as reducing clock speed when the processor reaches its thermal control limit and documents automatic shutdown when thermal protection cannot keep temperature under control. AMD Ryzen Master exposes a processor-specific Max Temperature at which thermal throttling of clocks and voltages occurs. NVIDIA likewise documents separate GPU slowdown, maximum-operating, and shutdown temperature fields.

Those mechanisms do not justify one universal temperature threshold for every CPU or GPU. Check the exact processor, graphics card, firmware, and vendor telemetry. A component approaching or entering a documented thermal limit is useful evidence; a normal-looking temperature at one sensor is not proof that every other component or power stage is healthy. Record temperature, clock behavior, fan behavior, and the exact moment of failure together.

Verify cooling behavior with the system powered down before assuming the cooler is defective

If the failure correlates with rising temperature, inspect the ordinary cooling path with the machine shut down: cooler mounting that was recently disturbed, fan and pump connections, blocked intakes, heavy dust buildup, and whether the expected fans actually spin under load. AMD stability guidance specifically recommends verifying CPU, graphics-card, power-supply, and system cooling and improving obstructed airflow.

Keep this observational. Do not open a power supply, probe mains voltage, bypass fan controls, or improvise wiring. If a CPU cooler was recently replaced or remounted, use the exact cooler and motherboard documentation for installation rather than turning this page into another physical cooler-compatibility guide.

Inspect the external and low-voltage power path without treating a protection trip as a PSU verdict

A load-triggered power-off can be related to the power path, but the symptom is not specific enough to identify the PSU by itself. With the PC fully powered down and disconnected as appropriate for the hardware manual, verify the normal user-serviceable connections that may have been disturbed: the PSU AC lead, motherboard main power, CPU/EPS power, GPU auxiliary power, and the exact modular cables approved for that PSU.

Power supplies can also contain protective shutdown mechanisms. Corsair documents over-voltage, under-voltage, over-current, over-temperature, short-circuit, and over-power protections that can shut a PSU down when their conditions are reached. A shutdown therefore says only that the system lost or interrupted normal operation; it does not tell you whether the cause was an overloaded or faulty PSU, a connector/cable problem, another component, thermal protection, or something else. Never open the PSU or swap modular cables between models unless the manufacturer explicitly approves that exact cable.

Change the workload one dimension at a time to see what actually triggers the failure

Use controlled comparison rather than random part swapping. Compare a known CPU-heavy workload, a known GPU-heavy workload, and a combined workload only when those tests are appropriate for the machine and you can stop them if temperatures or behavior become abnormal. The useful result is not a benchmark score; it is whether a particular load class reliably reproduces the restart while another does not.

A GPU-only failure does not automatically prove the graphics card is defective because GPU load also changes PSU demand, case temperature, drivers, and graphics-card tuning. A CPU-only failure likewise does not isolate the processor by itself. A failure that appears only when CPU and GPU are loaded together can strengthen the case for a shared power/thermal constraint, but it still needs supporting observations before replacing hardware.

Keep RAM profile instability as a separate branch instead of retuning memory here

If the machine is stable at default memory settings but restarts, freezes, or reports errors after enabling XMP/EXPO, that is meaningful evidence that the profile configuration is part of the failure. AMD and Intel classify these profile/tuning mechanisms as overclocking, and Core Tech Tips already has a dedicated workflow for profile availability, CPU/board/population limits, training, fallback, and stability.

Do not respond by inventing DRAM, SOC, VDD, VDDQ, subtiming, or memory-controller values. Confirm the default baseline and follow the RAM Running Slower Than Rated troubleshooting page. If the system no longer completes POST after the profile change, move to the no-POST workflow instead.

Use Windows Event ID 41 to confirm an unclean restart, not to diagnose a failed PSU

Windows records Kernel-Power Event ID 41 after a reboot when the previous shutdown was not clean. Microsoft explicitly notes that Event ID 41 by itself may not contain enough information to define what happened. The same event can follow lost power, a hard hang, a forced shutdown, or a Stop error, so seeing “Kernel-Power 41” is not evidence that the PSU has failed.

Read the event details and surrounding timeline. A recorded bug-check code or a separate Windows Error Reporting Event ID 1001 can point toward a Stop error path; Event ID 6008 records that the prior shutdown was unexpected. Absence of a useful bug-check code can also occur when the machine loses power or stops too quickly for Windows to write more detail. Treat the log as chronology and evidence, not as a component-replacement instruction.

WHEA and driver or application evidence can narrow the branch, but still need context

Windows Hardware Error Architecture records hardware error events in the System log through the Microsoft-Windows-WHEA-Logger provider. A WHEA record is materially different from Kernel-Power 41 because it represents hardware-error information reported through WHEA, but the exact record still needs interpretation. Do not reduce every WHEA entry to “the CPU is bad” or another one-component verdict.

Likewise, if only one game or application closes while Windows remains stable, investigate that application and its driver/software path before treating the event as an abrupt system-power failure. Microsoft recommends reviewing surrounding reboot history, bug-check records, updates, drivers, and other events because correlation around the failure can narrow the investigation even when no single event proves the root cause.

Use a bounded evidence-first order and escalate only when one branch has supporting observations

Use this order: 1) classify the failure as app crash, Stop error, freeze, restart, or abrupt power loss; 2) record exactly what workload reproduces it; 3) return user-applied CPU/GPU/RAM tuning to documented defaults; 4) observe temperatures, clocks, fans, and cooling behavior; 5) with the system safely powered down, verify the normal external and low-voltage power connections and exact approved PSU cables; 6) compare CPU-heavy, GPU-heavy, and combined load behavior where appropriate; 7) branch memory-profile issues to the dedicated RAM workflow; 8) review Event ID 41, bug-check/Event 1001, WHEA, and surrounding events; 9) only replace or professionally test hardware when the accumulated evidence points to that component or path.

Stop immediately if there is burning smell, visible electrical damage, liquid exposure, sparking, damaged mains wiring, or another condition that makes continued testing unsafe. Otherwise, preserve one change at a time and record the outcome. That produces stronger evidence than replacing the PSU because Event 41 appeared, replacing the CPU because it throttled, or declaring the GPU faulty because a combined gaming load happened to trigger the restart.

Sources

Primary and technical sources

Technical details can vary by exact model, firmware, and platform. These are the sources used for the factual claims in this article.

  1. 01 Microsoft

    Advanced troubleshooting for Event ID 41 and what the event does and does not establish
  2. 02 Microsoft

    Unexpected reboot Event IDs, bug-check evidence, and surrounding system-event history
  3. 03 Microsoft

    WHEA hardware error events and System log recording
  4. 04 Intel

    Intel processor throttling and thermal-protection troubleshooting
  5. 05 AMD

    AMD Ryzen Master Max Temperature and thermal-throttling definition
  6. 06 NVIDIA

    NVIDIA GPU slowdown, maximum-operating, and shutdown temperature telemetry definitions
  7. 07 Corsair

    Power-supply protection mechanisms including OVP, UVP, OCP, OTP, SCP, and OPP
  8. 08 AMD

    System stability troubleshooting, restoring default tuning, cooling, and memory checks
  9. 09 AMD

    AMD Software GPU tuning defaults, reset controls, telemetry, and stability stress-test behavior
  10. 10 AMD

    Ryzen Master default/stock tuning modes and reset controls for CPU and memory

Related