Computer Technicians 104: Making Computer Diagnoses

Previously, on TNCT 103, we explained the most critical component in a computer system. While knowing the insides of every component is crucial to becoming a knowledgeable (if not even good) technician, one of the biggest challenges when repairing any computer is definitely making a diagnosis.

Making diagnoses is probably one of the toughest parts of the job. Yes, in most cases, getting a steady supply of clients can be daunting, but making an accurate prognosis of what’s really wrong with the computer is something that’s just bound to give you a headache, both when you’re new to the job and when you can already repair in your sleep. In the former case, it’s because you can’t think of what’s wrong; in the latter, it’s because you can think of too many possibilities. Either way, you’re bound to get a light headache, but once you let the dust in your head settle a bit, you’ll be able to coolly decide which course of action to take.

Gather your info while you may
The very first step in discovering what exactly is wrong with your target computer is a lot simpler than you might think. The moment you meet the client, try to get as much information about the problem. Now, in most cases, the client doesn’t really understand how the computer works, so what you’ll get can range from a pretty graphic “it goes past the first black screen, shows the Windows XP logo, turns blue and then restarts” to a very generic “it won’t start”. If it’s the former, you’ve already got material to start thinking. If it’s the latter, you’ll have to do a bit of questioning. Or, if the client really doesn’t know, watch the boot sequence with them, provided the machine even gets up to booting.
Generally, you can guess whether it’s the software or hardware’s fault from the moment things start going wrong. If something goes wrong up to the power-on-self-test (POST) procedure, it’s almost definitely a hardware fault – this includes the computer not booting up at all. Once it gets to booting, software comes into view, depending on the error – just looking at the Blue Screen message can give you an insight into what caused it. Once the desktop is up and operational, while hardware may be to blame in some cases (such as instant hangs, the screen going black and losing power or glitchy images), the fault is almost sure to be a software one. Granted, there are some pretty freaky occurences that’ll make you wonder how it wasn’t the hardware’s or software’s fault, but they’re just that – freaky occurences. End-user problems are a category on their own, unfortunately.

Bottom-up approach – see the stone, ignore the pebbles
Once you’ve determined the most likely cause of the problem, you need to mentally list off all the most obvious, accessible or common causes. In case of a failure to even start, the most obvious cause is the PSU, while the easiest to access are the power supply cables – both internal and external. In case of a POST error (accompanied by either PC speaker beeps), the most obvious cause would be the motherboard itself – however, in practice, the most common cause is an inadequately plugged expansion card or RAM bank. In case of an OS problem, the most obvious and common cause is either the OS itself or the last installed application which collided with something.
Generally speaking, once you’ve done quite a few repair jobs, you’ll already have a mental map of the most common causes and you’ll be able to generally guess what caused the problem – even to the point of knowing some oddball cases, such as graphical glitches being caused by fading video RAM. However, you should always lead yourself by the KISS rule – Keep It Simple, Stupid. By far the best way to diagnose is to always look at the big players – the PSU, the motherboard, the RAM and the OS. While a sound card for instance, can cause a lot of trouble if it malfunctions, it’s among the rarest troublemakers. Ironically enough, a CPU failure, which is the brain of the average computer, is just as rare unless the client’s been doing something extremely unsafe (and therefore, written off as a user error). Once you’ve diagnosed which general part caused the problem, you can start doing more detailed diagnostics.