In the Room
What a Memory Test Proves, and What It Does Not
A memory test, SMART attributes, voltage sensors, and a burn-in run each answer a narrow question. Here is what PC stability diagnosis can and cannot establish.
Pieces in this section
-
Who gets paid when a record plays
Composition against sound recording, performing rights organisations against SoundExchange, and the statutory licence that covers streaming but not podcasts.
14 minute read4 notes
-
The wiring of a room that talks back
Console buses, the telephone hybrid, mix-minus, the profanity delay, and what happened when the wiring became a network.
13 minute read3 notes
-
Loudness, and the ceiling nobody can raise
K-weighting, gating, integrated loudness, true peak, and the ten unit gap between what broadcast asks for and what streaming platforms normalise to.
14 minute read4 notes
-
Microphones, and the six inches that decide everything
Dynamic against condenser, polar patterns, proximity effect, the inverse square law, and why the room usually matters more than the microphone.
12 minute read3 notes
A memory test proves only that the tested cells returned the expected pattern under the conditions the test created. It does not prove that the modules are good, that the memory controller is stable, or that the same cells will behave the same way at a different temperature, voltage, or clock. A clean pass is evidence about a window, not a verdict about the part.
The distinction matters because the tools are often read as verdicts. MemTest86, the standard since 1994, writes patterns into address ranges and reads them back, comparing bit for bit. A single mismatch is a hard failure and usually ends the argument: the module, the slot, or the controller is producing wrong data. A full pass with no mismatch is weaker evidence than it looks. The test covers the addresses it was given, at the timings and voltages in force at that moment, for the duration of the run. Errors that appear only above 60 degrees Celsius, or only when four DIMMs are populated instead of two, or only after the tenth hour, are outside that window.
What does a memory test actually prove?
It proves that a specific pattern survived a round trip through a specific address range under specific conditions. Everything else is inference.
Three limits are worth naming. First, coverage: a test that runs for one hour on 32 GB may not touch every cell under every pattern, and the standard advice to run several passes exists because pattern coverage is finite. Second, conditions: memory errors are frequently thermal or voltage dependent, so a pass at stock settings says nothing about the same modules at 1.35 V and DDR5-6400. Third, the boundary: the test exercises the module and the path to it, but a fault in the CPU's integrated memory controller, in the board's trace routing, or in the power delivery can produce identical symptoms and survive a clean memory run.
A practical reading is to treat a failure as conclusive and a pass as provisional. If a machine crashes under load but passes memory testing, the memory is not cleared; the test simply did not reproduce the conditions that break it. Raising the case temperature, adding the missing DIMMs, or extending the run is how the window gets widened. For a method that treats each result as bounded rather than final, the hardware diagnosis notes at the burn-in and diagnostic guide lay out the same logic across memory, storage, and sensors.
How are SMART attributes and voltage sensors read?
SMART is a set of counters a drive's own firmware maintains and reports. The raw numbers are vendor-specific, which is the first trap: attribute 5, Reallocated Sector Count, means roughly the same thing on most drives, while attribute 231 or 241 can mean different things on different controllers. The normalized value, usually 100 or 200 at new, falls as the raw count rises, and the threshold is the point at which the firmware itself will flag the drive.
The attributes that carry weight are the ones that only move in one direction. Reallocated sectors, pending sectors, and uncorrectable errors are cumulative; a drive with 40 reallocated sectors is not the same as a drive with zero, even if both are far from their thresholds. Attributes such as temperature or power-on hours move both ways and describe conditions, not damage. Reading SMART means separating the two groups and watching the first group over time rather than at a single moment.
Voltage sensors are read the same way, with the same caution. A board reports 12 V, 5 V, and 3.3 V rails through a supervisory chip, and those readings pass through a divider and an analog-to-digital converter before reaching software. Accuracy is typically plus or minus 2 to 5 percent, and some boards are worse. A 12 V rail reading 11.8 V is inside the ATX specification, which allows plus or minus 5 percent, and is not by itself a fault. What matters is movement under load: a rail that sags from 12.05 V at idle to 11.6 V during a stress test is telling a story that a single idle reading hides. Software such as HWiNFO or the board vendor's utility can log these values over time, and the log is more useful than the snapshot.
Temperature sensors have their own limits. CPU package temperature is a computed value, not a direct measurement, and per-core readings can differ by several degrees. The number to watch is the distance to the thermal limit, not the absolute figure, because a chip rated to 95 degrees Celsius is not in trouble at 80.
What does a burn-in run establish, and what are its limits?
A burn-in run establishes that the system completed a defined workload for a defined period without a detected error. That is the whole claim. It is a negative result, and negative results are bounded by the workload and the duration.
Stress tools such as Prime95, OCCT, y-cruncher, and the various memory-specific tests load different subsystems. Prime95's small FFT mode drives the CPU cores and the power delivery hard with little memory traffic; its blend mode mixes in memory. A system that passes one and fails another has told you where to look, not that it is stable. Duration follows the same logic: a one-hour pass is a smoke test, a twelve-hour pass covers more thermal cycles and more of the failure modes that appear once the case has soaked, and no duration covers the error that appears in month three.
Reading an instability is its own skill. A crash to a black screen, a bluescreen with a memory management stop code, a worker thread that stops while others continue, and a silent wrong result are four different signatures. The first two point at power or at the memory path; a stopped worker in Prime95 usually points at core voltage or core stability; a silent wrong result is the one that matters most and the one a pass or fail summary can miss. Logging is how it gets caught.
The cumulative risk is the part that gets skipped. Every hour at elevated voltage and temperature adds electromigration and oxide wear, and the damage does not reset when the settings do. A burn-in run at 1.45 V and 95 degrees is not a free test; it spends some of the part's life to answer a question. The measured approach is to raise one variable at a time, keep the thermal ceiling in view, and stop when the answer is in.
How is a live diagnostic USB stick built?
A live USB stick boots its own operating system from removable media, leaving the installed drive untouched. That is the point: a machine that will not start its own OS can still be tested, and a drive that may be failing can be read without writing to it.
The build starts with a known image, written to the stick with a tool that verifies the write. The toolkit on top is the part that needs maintenance. MemTest86 is the memory layer. Smartmontools provides smartctl, which reads the attributes described above and can run a drive's own self-test. Stress tools cover the CPU and memory path. Sensor utilities read the rails and the temperatures. A partition tool and a file recovery utility handle the storage side. Each of these has a release cadence, and a stick built in 2019 will carry a smartctl that does not recognize a 2023 drive's attributes.
The historical reference point is the Overclockix project, which distributed live CD and USB images from 2003 to 2015 and documented a per-subsystem matrix of which tool answers which question. That archive is a method, not a download: the releases are old, but the mapping from symptom to tool has not changed much. Building a current stick means taking that matrix and filling it with maintained packages.
Where the method ends
Every tool here answers a narrow question under stated conditions. A memory pass covers the addresses and the moment. SMART describes a drive's own accounting. A sensor reading carries the error of the chip that produced it. A burn-in run covers a workload and a duration. The method is to know which question is being asked, and to treat a clean result as a smaller claim than it first appears.
A memory test, SMART attributes, voltage sensors and a burn-in run each answer a narrow question, and none of them speaks to what happens when the failure is not electrical but human. A machine that passes every check can still be undone by a clicked link, a lost phone or a locked file. The two domains stay separate, yet the habits overlap: both reward a fixed order of steps taken early. Readers who want that order for accounts and devices can follow the first hour after an incident, which lays out the sequence and a one-page plan for a small team.