Intermittent faults: heat, power, and the ones that come back

Why this matters

An intermittent fault is the most expensive kind. It resists the method from lesson 34 at every step: the symptom cannot be observed on demand, so identification is hard; a theory cannot be tested reliably, so any test that passes proves nothing; and verification is impossible, because a machine that has not failed for an hour may simply not have failed yet.

That is why intermittents get "fixed" repeatedly. Somebody changes something, the fault does not recur that afternoon, the ticket closes, and it comes back next week. Each round consumes a visit and teaches nobody anything.

The way out is to treat it as a measurement problem first. If you can make the fault happen on demand, or capture evidence while it is happening, it becomes an ordinary fault. Most of this lesson is about how to do that.

The lesson

Why an intermittent fault is a measurement problem before it is a repair problem

The defining difficulty is that absence of the fault is not evidence. A machine that ran for two hours without crashing has told you nothing, because it ran for two hours yesterday too.

So the first objective is not to fix anything. It is to establish:

• Under what conditions does it occur? Load, temperature, time of day, after a period of use, when a particular application runs, when a cable is moved.
• How often, in a stated period? "Three times a day" is a measurement; "sometimes" is not, and only the first can show that a change helped.
• What is recorded when it happens? Event logs, error codes, temperatures at the moment of failure.

That third one is what turns the problem around. A machine that logs its temperature every ten seconds and crashes at 99 °C has diagnosed itself. A machine that nobody instrumented has not.

Practical instrumentation on an ordinary machine: the operating system's event log, hardware monitoring software recording temperatures and voltages to a file, a stress-test tool to force the condition, and a note from the user of the date and time each occurrence.

Thermal faults: the pattern that identifies them, and how to force the condition

Thermal faults have a signature that is nearly unmistakable once known:

• The machine works from cold and fails after a period of use.
• It fails sooner on a warm day, or in a confined space, or with the side panel on.
• It recovers after being left off, and the recovery time is roughly a cooling time.
• Failure correlates with load, not with elapsed time.

Forcing the condition is the whole game, and it is straightforward: run a stress test that loads the processor and, separately, the graphics, while logging temperatures. A fault that appears within minutes under load and never appears at idle is confirmed thermal — and that is a diagnosis reached in fifteen minutes rather than three visits.

What to look at once confirmed, in order:

1. Dust in the heatsink and fans, which is the most common cause and the cheapest fix.
2. Fans actually spinning, including the graphics card's, which often only spin under load.
3. Thermal paste, which dries out over years. Re-pasting a five-year-old machine can drop temperatures substantially.
4. Cooler mounting, which can loosen; a cooler that moves when nudged is not making contact.
5. Airflow, from lesson 28 — case fans, blocked intakes, a machine in a cupboard.
6. Ambient temperature, which is a legitimate answer: a machine in a sunlit window or a sealed cabinet is failing correctly.

The distinction between throttling and shutdown matters. Throttling is protective and presents as "it gets slow after a while". Shutdown is the temperature limit being hit and presents as an abrupt power-off with no warning and no error — which users describe as "it just dies", the same words they use for a power fault.

Power faults under load, and why a machine idles fine and fails under work

Power faults share the load correlation with thermal faults and differ in timing: a power fault usually strikes immediately when load rises, whereas a thermal fault takes minutes to build.

The signatures:

• Reboots or shutdowns the instant a game, a render or a benchmark starts.
• Random reboots with no operating system error, because there was no time to write one.
• Several unrelated components appearing faulty at once — lesson 28's warning.
• A machine that works with the graphics card removed.
• Faults that started after adding a component that draws more power.

Beyond the supply itself, the mains side matters and is often ignored:

• A failing or overloaded extension lead or socket.
• Voltage sag when something else on the circuit starts — a kettle, an air conditioner, a laser printer on the same circuit is a genuine and common cause in small offices.
• An uninterruptible power supply with a failed battery, which can pass power through poorly.
• Loose mains cable at either end.

The tests: substitute a known-good power supply, which is definitive; measure the rails under load, which lesson 43 covers; move the machine to a different circuit; and try the machine without the highest-draw component fitted.

Capturing evidence while the fault is present, since it will not be present later

The core discipline. What to capture, and how:

• Photograph or video the screen at the moment of failure. Users can do this with a phone, and a stop error code or an on-screen message is worth more than any description of it.
• Event logs. After an unexpected shutdown the system records it, and the entries immediately before are the useful ones. A critical "system rebooted without cleanly shutting down" entry with a timestamp gives you the moment to look around.
• Temperature and voltage logs written to a file continuously, so the values at the failure moment survive the reboot.
• A user-kept record: date, time, what they were doing. Three entries usually reveal a pattern that nobody had noticed.
• Do not reboot immediately when you are present for the fault. A frozen machine still holds information — is it responsive to the keyboard, do the lights show disk activity, is it hot, are the fans running.

That last point is where step one of the method and intermittent faults conflict, and the method wins: rebooting is cheap and fast, and it destroys the only evidence you were going to get.

Knowing when a fault has been fixed rather than merely not reproduced

The hardest judgement in this lesson, and a real professional obligation.

The standard to aim for:

• You identified a cause, not merely a change that seemed to help.
• You can explain the mechanism — why that cause produces that symptom.
• The fault reproduced before the fix and does not reproduce after, under the same forcing conditions.
• The machine has run past the previous failure interval. If it failed daily, a day of good behaviour is weak; a week is evidence.

Where that standard cannot be met, say so. "Replaced the power supply, which measured low on the 12 V rail under load; monitoring for a week" is an honest handover. "Fixed" is not, and it is how a machine gets three visits.

Two related habits. Change one thing at a time, so that if the fault stops you know what stopped it — and if you must change several because a visit is expensive, record that the diagnosis is correspondingly weaker. And leave the instrumentation running after the fix, because a logging tool that stays installed turns the next occurrence into an immediate answer instead of another cycle of this lesson.