Computer Technicians 104: Making Computer Diagnoses

Under a looking glass
Once you’ve detected the general cause of trouble, go extremely specific. In this case, you’re applying the exact opposite of the bottom-up approach. Suppose you’ve discovered the RAM went bad – power the computer down, take all the RAM sticks out and insert only one. Boot, test, reboot, repeat test. If it’s good, that means one of the others went sour, so repeat the test. Maybe the two RAMs from the batch don’t like each other? Repeat the test with both, alternate slots, try different slot layouts (i.e. 1-2, 1-3, 2-4…), and see which combinations boot up, which don’t, and which work flawelessly. When dealing with PSUs, the general idea is to try and see if a lower load will do the trick – unhook a big ventilator or one of the optical drives and get the extra 15W leeway. If the drivers are acting up, for instance, first fiddle with the settings a bit, then if nothing helps attempt to reinstall the drivers. In short, once you’re examining the area creating the trouble, attempt anything and everything, but one thing at a time. If something doesn’t help, revert back and try something else.

PEBCAK
Ah. The famous six-letter acronym. Standing for Problem Exists Between Chair and Keyboard, this is a special category that deserves thorough explanation. Although neither a hardware nor a software failure, PEBCAKs are the leading cause of grief among technicians both new and old. In case the user did something on their own and can’t revert it, there are two possible solutions. One, the client just tried to experiment (which happens all too often) – you’ll probably lose a few years of life and some hair over it. Two, the user did it according to a more detailed manual or guide, and generally knows what they did – still a slightly tough job to do, but not nearly as much. Either way you look at it, PEBCAKs are the worst category of problems, especially if the client really, really, really doesn’t like reading manuals, or looking at instructions, or even warning labels. If the client doesn’t admit what they did, you’ve got to go through the whole procedure – it’s only human nature not to admit your error, but it’s a techie’s nightmare.

To sum it all up: when you come to a job, start with a clean mental slate and test the obvious causes first. Don’t be afraid to ask the client in order to figure out what happened, but don’t outright interrogate them. Once you detect the global problem, immediately try detailed solutions, alternate diagnostic tools and hardware solutions (such as swapping components’ places or leaving them out) – in other words, know what you’re looking for, experiment with it and sharpen your image of what’s the real problem and how to fix it. Arriving with a mind open to any possibility is the best solution because you won’t hinder yourself with assumptions from previous jobs. Once you get to details, let your experience give you a bit of insight – maybe, just maybe, this’ll be your second fix of the same problem on different computers. Or, if you’re unlucky, the same computer, but that only means you need to revise your conclusions. Have a plan, use common sense, and above all, be couragous enough to try and solve. Even if you can’t solve the problem, a correct diagnosis might help both you and the client.

 
Written by Boris M