Diagnosing faults

Our troubleshooting tips

This is one of the hardest things to "teach" - it is mostly learned through experience. This is like a kungfu dojo - the more you practice, the more you have confidence in the tools/process. But here are some tips

What to avoid

• Don't leap to easy conclusions!
• Avoid "blind alleys"

Gathering the evidence

We have a number of ways to gather evidence about the fault, often we have to mix and match.

• Description of the fault from the owner/user (sometimes this can be misleading and/or 'wrong')
• Nature of the onset
• Visual evidence
• Passive testing (e.g. with a meter - resistance can be useful)
• Functional testing (when safe and possible)

Following a logical process

• It really helps to know how something works! (This may sound obvious, but it's worth reading about how the e-thing works.)
• Start investigating in a logical, sequential way where you move from parts you know are working towards parts you know are not working.

Root cause or causal factor?

• Fixing the "root cause" will permanently clear the fault.
• Fixing only a "causal factor" (such as replacing a blown fuse) may make something work again, by the "root cause" may still be present and the fault will reoccur.

Cases

Kettle

Mysterious kettle owned by the venue - we did not know the circumstances of the fault.

• Check the fuse (ok)
• Visual inspection (ok)
• Tested for continuity from the mains plug to the base (ok)
• Tested base for resistance and continuity (ok)
• By logical process, the only thing left was the physical contact between the kettle jug and the base - turned out it was not making a solid contact and needed to be remade

Laptop

The laptop owner (a very expert user) told the Restarter the harddrive needed "debugging" - led to blind-alley

• Ran a harddrive diagnostic tool (ok)
• Mounted the drive (ok)
• Inspected system log (ok)
• Booted on Linux and noticed there was rubbish coming up on screen at boot - suspected a keyboard or touchpad fault - isolated the keyboard fault