The reception machine at Whitlock Dental restarts on its own, about twice a day, with no blue screen and nothing in the event log except the note that the previous shutdown was unexpected. Three people have already suggested reinstalling Windows. A machine that restarts without a blue screen is power or heat, not software, and a reinstall would have cost a day and changed nothing.
That sentence is the whole of this topic in one line. Hardware faults have a small number of shapes, each shape has a signature, and the work is reading the signature rather than replacing parts until the symptom stops.
Three commands before opening the case
Counting the parts that could plausibly produce this symptom gives 12 to start with: the supply, the board, the processor, the cooling, four memory modules, the disk, and three things plugged into it. The absence of a crash log takes it to 7 by removing everything that would have been reported by software. One disk command takes it to 5. None of that required a screwdriver, and the order matters more than the arithmetic.
The machine is still running most of the time, which means it can be asked questions. The first is about the disk, because a failing disk produces symptoms that look like almost anything.
smartctl -H /dev/sda- prints
SMART overall-health self-assessment test result: PASSED
smartctl -H /dev/sda prints PASSED or FAILED in one line, and it is reading the drive's own record of reallocated sectors and read errors rather than guessing from behaviour. PASSED is not a clean bill of health, because a drive can be failing in ways the self assessment does not fail on, but FAILED is conclusive and ends the investigation immediately.
The second question is temperature, and it is the one that matches this fault. Sensors reports the core temperature, and a thermal shutdown is not a crash. A processor that reaches its limit turns the machine off rather than damaging itself, which is why there is no crash log: nothing crashed. The operating system was not consulted. On the Whitlock machine the cores sit at 94 degrees within four minutes of the practice management software opening, and the shutdowns happen in the busy hours.
The third is memory, and it is the slowest test on this page. One memtest error is one too many. A single bit flipped in four hours of testing is a failing module, not a marginal one, and memory faults produce the most confusing symptoms in computing because they corrupt whatever happened to be in that address: a different application each time, a different error each time, and a strong impression that the machine is haunted.
The rule that makes any of it mean anything
The instinct under pressure is to change several things at once, because the practice wants the machine working and each change is quick. Swap one part at a time, or the test tells you nothing. Two changes and a fixed machine leaves you not knowing which one fixed it, which matters because the other one is now a part you have removed from stock for no reason, and because the fault will return if you guessed.
The corollary is the one people find harder: reseating a component is a test rather than a repair. If pushing a memory module back in fixes the machine, the module was not seated, and the question is why, which is usually that somebody moved the case. Recording that it was reseated and considering it closed is how the same machine arrives back in six weeks. This discipline is the whole content of isolating a fault instead of replacing parts.
What the fault turned out to be
The heatsink on the Whitlock machine was clamped on three of its four corners. The fourth clip had never been closed, which is a manufacturing miss rather than a failure, and the machine had run for two years because until the practice moved to software that actually uses the processor it never got warm enough to matter. Reseating the heatsink with fresh paste brought the load temperature to 61 degrees and the restarts stopped.
Nothing about that repair required knowing what a heatsink is made of. It required knowing that the symptom named a category, and the parts and what each of them does are laid out in the parts, and what each actually does.
The habit
Replacing until it stops, against asking until it is named
Three of the four rows favour testing. The fourth is real and is why the swapping habit survives.
The last row is why the habit persists in a busy practice, and it is a real constraint rather than laziness. The answer is to start the slow test first and swap while it runs, not to choose one column.
The order, and where people stall
The order that works is the symptom, then the category, then the part. Most people learn it in the opposite direction, from choosing parts that fit, and assembling them, which teaches what the components are and teaches nothing at all about what a failing one sounds like.
The stall is specific and it is a confidence problem rather than a knowledge problem. Somebody can build a machine from parts, is asked to fix one that is already built, and finds that the skill does not transfer, because building is a task with an end state and diagnosis is a search. That gap is where most people quietly decide they are not a hardware person, and it is entirely a matter of never having been given a method. The method is on this page, and the job that consists of applying it eight times a day is the job most technical careers start in.
What to open, in 2026
For the disk, smartutils supplies smartctl on every platform and is free. It replaced the manufacturer's own bootable diagnostic tools, which meant taking the machine out of service to answer a question that can now be asked while it is running.
For memory, memtest86+ is free, open source, and boots from a USB stick. It replaced the practice of swapping modules and waiting to see whether the problem came back, which takes a fortnight and produces an answer nobody trusts. Give it one full pass, which on 16 gigabytes is a few hours, and run it overnight rather than between patients.
For temperature and everything else the machine will tell you about itself, lm-sensors on Linux and the free HWiNFO on Windows both read the same onboard chips, and both replaced the era of putting a hand on the case. The laptops and phones this pillar also covers have their own version of every one of these problems and almost none of the same access, which is what makes portable machines, and what is different about servicing them a separate subject.
What none of this settles is what to do when the machine is fine and the thing on it is not, which is the layer above and is where the machines, the networks between them, and keeping both standing goes next.