The most important step in resolving computer problems is isolating a root cause of the issue. One way to get to the heart of the matter is by attempting to replicate the problem when booted from software you can trust.

————————————————————————————-

I first heard the term binary search when I was taking a computer programming course in college. Essentially, binary search is a tactic used to find a specific value by evaluating subsets of all the possible values. If you can keep eliminating half the possible solutions from consideration, you quickly arrive at the answer you seek.

When answering a support call, the first question I ask myself kicks off a binary search of sorts: Is this a hardware problem or a software problem? The sooner I can remove a class of failure from consideration, the fewer possible solutions I have to contend with.

Sometimes the answer to my initial question is simple. If a monitor is smoking…well, there you go . . . that’s likely a hardware problem. But most computer issues are not so obviously solved. Since our computers use software to interact with the various internal and external components, what appears to be a hardware problem could be attributable to a corruption in device drivers or operating system components.

So, once I’ve replicated my client’s problem in their software, I like to use software of my own to see if the issue persists. I carry two types of bootable media: a CD/DVD and a USB hard drive. The USB drive lets me carry a complete OS installation with a full load of device drivers and diagnostic utilities. The optical disk is usually a “live” Linux distribution that can boot many machines using generic drivers. The key to using known-good software for troubleshooting is making sure that the software is trustworthy. I reimage my USB drive frequently and make sure my test software is patched. If I’m concerned about the health of the network, I usually use my optical boot disk. It’s read-only, so there’s no chance I’ll carry away something unsavory from an infected machine.

If a customer’s problem persists when booted from my software, I begin to presume that a hardware failure is involved. If using my boot disk makes the problem disappear, then I know to take a closer look at the health of my client’s software installation.

Testing with a known-good component is vital to isolating hardware issues. By using the same principle to test your clients’ software, you can make sure you are getting to the heart of the issue in the most efficient way possible.