Windows 11 PC Randomly Restarts: Diagnose Bugchecks, Power Loss, Thermals, and Hardware Instability

A PC that “randomly restarts” can be reaching several very different failure paths. Windows may detect a fatal condition and perform a bug check, the machine may lose or interrupt power too quickly for Windows to record a stop error, firmware or unstable hardware may reset the system, or the PC may hang until it is forced off. Start by identifying which path left evidence rather than replacing parts based on the symptom alone.

This page owns that classification workflow. If you already have a repeatable Windows stop code or crash dump, use the dedicated Windows 11 BSOD troubleshooting guide for deeper dump and bug-check analysis. If Windows never starts successfully and repeatedly returns to recovery or startup failure, use the boot-loop workflow instead.

After an unexpected shutdown or restart, Windows can log Microsoft-Windows-Kernel-Power Event ID 41 at the next startup. Microsoft explicitly says the event means Windows detected that the previous shutdown was not clean and that Event 41 by itself may not contain enough information to define what happened. A power interruption, a stop error, a hard hang, or another abrupt reset can all lead to the same event.

Open Event Viewer and correlate the restart time with the System log. Inspect the Event 41 details rather than stopping at the word “Critical.” A nonzero BugcheckCode can point toward a Windows stop-error branch. Microsoft also documents WER-SystemErrorReporting Event 1001 as evidence that the computer rebooted from a bugcheck and may name a saved dump. Conversely, zero bug-check fields do not prove that the PSU is defective: power loss is one possibility, but Windows may also have been unable to finish recording crash information.

If the System log, a stop-code screen, Event 1001, or a memory dump shows that Windows bug-checked, preserve the code, parameters, dump path, exact time, workload, and recent changes. Windows can restart quickly after a fatal error, so a user may experience a bugcheck as an apparently instant reboot. The dump and event evidence are more useful than whether the stop screen was visible long enough to read.

Do not translate one bug-check name into a failed component. Drivers, corrupted state, unstable memory, firmware, tuning, or hardware can surface through the same broad failure class. Repeated dumps and a consistent correlation with one change or workload are stronger evidence. The separate BSOD canonical covers WinDbg and dump interpretation when this branch is confirmed.

Record whether the reset happens at idle, during gaming or rendering, during sleep or wake, immediately after boot, or only after the machine has been running for a while. Note changes that preceded the first failure: Windows or driver updates, BIOS or firmware changes, a new GPU or storage device, moved power cables, a memory profile, overclock, undervolt, curve tuning, new peripherals, or physical work inside the case.

Change one variable at a time. A restart that began immediately after one known change gives you a controlled rollback test; changing drivers, firmware, RAM settings and cabling simultaneously destroys that evidence. Back up important data before repeated instability testing because abrupt shutdowns can interrupt writes and cause data loss or corruption.

If CPU, GPU or memory tuning is active, test at the manufacturer-supported defaults before escalating. That includes CPU or GPU overclocks and undervolts, curve or boost tuning, and memory overclocking profiles such as XMP or EXPO. A configuration that normally appears stable can still fail under a particular workload, temperature, sleep transition, or transient load.

A successful defaults test implicates the changed configuration, but it still does not prove a component is physically defective. If the system continues to restart at documented defaults, preserve that result and continue down the evidence-led branches below rather than immediately increasing voltage or replacing hardware.

Windows 11 includes Windows Memory Diagnostic. Microsoft documents launching it with mdsched, saving your work, and selecting the option to restart and check for problems; the tool can also run an Extended test set. A detected memory error is useful evidence that the memory subsystem or its configuration needs investigation.

A clean Windows Memory Diagnostic result is not a universal certificate that every RAM module, memory-controller setting, motherboard trace, profile, or workload is stable. If memory remains strongly correlated with the resets, compare documented-default settings and controlled module or slot configurations according to the motherboard manual. Do not hot-swap DIMMs or work inside a powered system.

Log CPU and GPU temperatures and clocks around a repeatable workload when thermal behavior is suspicious. Look for correlation: does the restart consistently follow sustained load, a fan or pump failure, a sudden loss of cooling telemetry, or another reproducible thermal condition? Inspect fans, pump operation where applicable, heatsink mounting, dust blockage, and airflow with the system safely powered down when physical inspection is needed.

Do not apply one internet temperature limit to every processor or GPU. Thermal limits, boost behavior and protection mechanisms are product-specific. Compare observed behavior with the exact CPU, GPU, cooler and system manufacturer documentation. A high reported temperature can explain throttling without proving that it caused an abrupt reset, and a normal temperature reading does not clear the rest of the power or stability path.

For a desktop that loses power or resets abruptly under load, inspect the external power connection and the internal power path with the machine shut down and disconnected. Confirm that motherboard and GPU power connectors are fully seated, that modular PSU cables belong to that exact PSU model or documented compatible family, and that any GPU connector or adapter follows its manufacturer installation requirements. Never mix modular PSU cables merely because the connector physically fits.

Power supply failure, protection triggering, poor connections, wall-power interruption, motherboard faults, and other instability can produce similar symptoms. Event 41 does not distinguish them. Do not choose a replacement PSU from a universal wattage rule: use the actual CPU/GPU/system requirements, connector needs, PSU documentation and observed failure pattern. If electrical damage, burning, arcing, liquid exposure or unsafe mains behavior is suspected, stop testing and use qualified service.

When evidence points toward a recent driver or Windows change, use its supported rollback or update path and retest the same workload. When a specific peripheral or newly installed component correlates with the restart, remove or substitute only that variable when it is safe and supported. If the failure happens across unrelated software and persists at documented firmware defaults, hardware or platform instability becomes more plausible, but still requires component-level evidence.

Keep a short test log: configuration, workload, duration, result, relevant event IDs, dump presence, temperatures and the one variable changed. This prevents “it seemed fixed” conclusions after a single short run. Avoid uncontrolled torture testing when the machine is already showing electrical, cooling or storage-integrity warning signs.

A useful order is: 1) back up important data; 2) classify the restart using Event Viewer and bugcheck/dump evidence; 3) record workload and recent changes; 4) return tuning to documented defaults; 5) test the most strongly implicated software, memory, thermal or power branch; 6) isolate one component or configuration variable at a time; 7) escalate with logs, dumps and repeatable test results to the system or component vendor.

Use the BSOD guide when a bugcheck is confirmed, the boot-loop guide when startup itself is failing repeatedly, and the dedicated temperature, RAM, PSU, driver or Windows Update troubleshooting pages when the evidence narrows to those domains. Random restarts are a symptom category, not a component diagnosis. The goal is to turn an ambiguous reboot into a reproducible branch with evidence before making disruptive changes or buying replacement hardware.