PC stability and diagnosis: a practical method
How to test memory, read SMART attributes, judge sensor limits, run a burn-in long enough, and build a diagnostic USB key for an unstable PC.
- Published: 13 September 2026
- Editorial guide
- By Editorial Desk
An unstable PC is not fixed by guessing. You confirm stability by testing one subsystem at a time, reading the result for what it actually covers, and repeating the test long enough to catch an intermittent fault. Memory, storage, temperature and voltage each need their own check, and no single number proves the whole machine is sound.
Start with memory, because it explains the most
Memory errors produce the widest range of symptoms: random reboots, corrupted files, failed installs, blue screens with different codes each time. A memory test is therefore the first thing to run on a machine that crashes without a clear pattern.
Use a bootable memory tester rather than a test inside the operating system. The OS occupies memory, so it cannot test the region it lives in, and it adds its own scheduling noise. A boot tester has the whole address space available.
Run at least two full passes before you believe a clean result. One pass catches gross failures, the kind that show up in minutes. Marginal cells often need temperature change or many hours of access before they fail. If you get an error, note the address and the test number, then re-seat the module and test it alone in the first slot. A single failing stick is a clean diagnosis. Errors that move between slots point at the board or the memory controller instead.
Be careful with the opposite conclusion. A clean multi-hour run lowers the probability of a memory fault, it does not eliminate it. Voltage drift, heat and timing interactions can stay hidden under a test that never reproduces the exact load of your real workload. Treat a pass as evidence, not as proof.
If you want a structured method for this kind of work, including which result covers which subsystem, the hardware diagnostic guides on Overclockix lay out the sequence and the limits of each test.
What do SMART attributes actually tell you?
SMART gives you a small set of counters that the drive firmware maintains about its own health. It is useful, and it is narrower than most people assume.
The attributes worth reading first are the reallocated sector count, the pending sector count, the uncorrectable sector count, and for solid state drives the wear leveling count and the percentage of rated life used. Rising reallocated or pending sectors mean the drive has already found bad areas and is remapping them. That trend matters more than the raw number: a drive with a few reallocated sectors that stays flat for a year is different from one that gains sectors every week.
The limits are real. Firmware decides what to report, and different vendors use different attribute numbers for the same idea. Some drives hide problems until they are severe. A drive can also fail suddenly with clean SMART data, because the failure is mechanical or electronic rather than in the media. And SMART says nothing about the cable, the port, the power supply or the file system.
So read SMART as one input. Combine it with the drive's own error log, with a surface scan if the drive is suspect, and with a backup that already exists. If SMART shows a rising pending count, copy your data off before you investigate further.
What does a stress test genuinely prove?
A stress test proves one thing well: that the machine survived that particular load, at that temperature, for that duration. It does not prove the machine is stable in general.
That distinction matters because people use a passed stress test as a verdict. A CPU stress test loads cores and caches in a specific pattern. It may not touch the memory controller the way your workload does, it may not stress the storage at all, and it may not reproduce the idle-to-load transitions where many faults appear. A graphics load tests the GPU and its power delivery, not the memory subsystem.
What a stress test is good for is comparison. Run the same test before and after a change, at the same ambient temperature, and you have a controlled observation. If a machine passes an hour before a timing change and fails in ten minutes after it, the change is implicated. That is a real result, and it comes from the design of the comparison, not from the test's authority.
Watch for the failure modes that stress tests miss. Errors that appear only after a cold boot, errors that need a specific combination of load on two subsystems, and errors that depend on ambient heat all escape a short run in a cool room. Log the temperatures and voltages during the run so you can tell a thermal failure from a logic failure.
How long does a burn-in need to run?
There is no universal number, but there is a defensible way to choose one.
Start with the failure rate you are trying to catch. If a fault appears within the first ten minutes of load, a one hour run will find it. If the fault needs heat soak, you need the machine to reach steady state temperature and then stay there, which often takes thirty to sixty minutes before the useful part of the test even begins. For a machine that fails once a day in normal use, a one hour burn-in is not a meaningful sample.
A practical schedule for a machine you are preparing to trust:
- Two full passes of a boot memory test.
- One hour of combined CPU and memory load, with temperature and voltage logged.
- One hour of storage load, with SMART read before and after.
- A repeat of the whole sequence after the machine has cooled completely, to catch cold-boot faults.
If the machine is for critical work, extend the combined load to several hours and repeat on a second day. The goal is not a magic duration. The goal is to have seen the machine pass under conditions close to its real use, more than once, with the sensors recorded.
Stop the burn-in if temperatures approach the manufacturer's limit or if voltages move outside the range the board reports as normal. A burn-in that damages the hardware has told you nothing useful.
How do you build a diagnostic USB key?
A diagnostic key is a small, maintained toolkit on removable media. It should boot on the machine you are diagnosing and give you memory testing, storage inspection, sensor reading and a live environment without touching the installed system.
What to put on it:
- A bootable memory tester.
- A live Linux environment with a terminal, so you can read SMART data and run storage tools.
- A SMART utility and a partition tool.
- A sensor reader for temperatures and voltages.
- A notes file where you record each session: date, ambient temperature, test run, result.
Build it on a known good machine, verify that it boots on the target, and label the stick with the version and the date you made it. Update it a few times a year, because tools age and a diagnostic key with stale utilities can mislead you.
Keep the key separate from your backups. Its job is to observe a failing machine, not to store the only copy of anything.
Reading a result without overreading it
The habit that separates useful diagnosis from guesswork is stating what a result covers. A memory pass covers the tested address range under the tested conditions. A SMART reading covers what the firmware chose to report. A stress test covers one load pattern for one duration. A burn-in covers the machine's behavior over the hours you ran it.
Write the limits next to the result. Then change one thing, test again, and compare. That method is slower than replacing parts at random, and it is the only one that leaves you knowing why the machine is now stable.