Absolute Beginners Guide to A+ Certification. Covers the Hardware and Operating Systems Exam

The oldest dilemma for any computer technician is determining whether a problem is caused by hardware or software. The widespread use of Windows operating systems makes this problem even more acute than it was when MS-DOS was the predominant standard, because all hardware in a Windows system is controlled by Windows device drivers.

The troubleshooting cycle is a method that you can use to determine exactly what part of a complex system, such as a computer, is causing the problem.

The first step is to determine the most likely source of the problem. The client interview will help you determine which subsystem is the best place to start solving the problem. In the previous example, the printing subsystem was the most likely place to start.

A subsystem is the combination of components designed to do a particular task, and it can include hardware, software, and firmware components . Use Table 22.2 to better understand the nature of the subsystems found in any computer.

Table 22.2. Computer and Peripheral Subsystems and Their Components

You can see from Table 22.2 that virtually every subsystem in the computer has hardware, software, and firmware components. A thorough troubleshooting process will take into account both the subsystem and all of its components.

The following steps are involved in the troubleshooting cycle:

1. Record the current configuration of the system or component.

2. Change one hardware component or hardware/software/firmware setting at a time; if you replace hardware, use a known-working replacement. The flowcharts and symptom tables in my book PC Help Desk in a Book can help you decide what to change first.

3. Retest after a single change and evaluate the results.

4. If you have no changes, return to the original component or settings and continue with the next item.

5. Repeat steps 24 until the subsystem performs normally. The last item changed is the problem; repair, replace, or reload it as appropriate to solve the problem.

Recording the Current Configuration

Before you change anything, record the current configuration . Depending on the item, this might include one or more of the following steps:

• Recording jumper or DIP switch settings

• Printing the complete report from the Windows Device Manager

• Recording BIOS configurations

• Backing up the Windows Registry

caution

Changing One Component or Configuration Setting at a Time

After you have recorded the configuration of the system, it's time to change one component in the subsystem you suspect is at the root of the problem.

The following are examples of changing a single component or configuration setting:

• Removing the device from the Windows Device Manager

• Changing a device's IRQ or other hardware resource setting

• Reinstalling a device's driver software

• Reinstalling or repairing an application

Performing two or more of these types of tasks before you retest the system can make matters worse , and if you fix the problem you won't know which change was the correct change to make.

"Known-Working" Doesn't Mean "New"Best Sources for Replacement Parts

To perform parts exchanges for troubleshooting, you need replacement parts. If you don't have spare parts, it's very tempting to go to the computer store and buy some new components. Instead, take a spare system that's similar to the "sick" computer, make sure that it works, and then use it for parts. Why? Just because it's new doesn't mean it works.

I once replaced an alternator on my van with a brand-new, lifetime-warranty alternator that failed in less than a week. Whether it's a cable, a video card, a monitor, or some other component, try using a known-working item as a temporary replacement rather than brand-new .

tip

If you don't have spare parts, use a spare system if possible rather than knocking another working system (and user ) out of action by " borrowing " parts from an operational system. Use the same brand and model of system for known-working spares if possible, because the components inside are more likely to be identical to the "sick" system you are diagnosing.

Where to Start? What Components to Check First

As the previous subsystem list indicated, there's no shortage of places to start in virtually any subsystem. What's the best way to decide whether a hardware, software, or firmware problem is the most likely cause? Typically, hardware problems come and go, whereas software and firmware problems are consistent. Why? A hardware problem is often the result of a damaged or loose wire or connection; when the connection is closed, the component works, but when the connection opens, the component fails.

On the other hand, a software or firmware problem will cause a failure under the same circumstances every time.

Another rule of thumb that's useful is to consider the least expensive, easiest -to-replace item first. In most cases, the cable connected to a subsystem is the first place to look for problems. Whether the cable is internal or external, it is almost always the least-expensive part of the subsystem, can easily come loose, and can easily be damaged.

If a cable is loose, has bent pins, has a dry, brittle, or cracked exterior, replace it. Good cables usually look good, and bad cables often look bad.

When new software or new hardware has been introduced to the system and a problem results immediately afterward, that change is often the most likely cause of the problem.

Hardware conflicts such as IRQ, I/O port address, DMA channel, and memory address, or conflicts between the software drivers in the operating system, are typical causes of failure when new hardware is introduced. New software can also cause problems with hardware, because of incompatibilities between software and hardware or because new software has replaced drivers required by the hardware.