Determining Whether a Problem Is Caused by Hardware or Software

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

Subsystem	Hardware	Software	Firmware
Printing	Printer, cable, parallel or serial port	Printer driver in Windows application	BIOS configuration of port
Display	Graphics card, monitor, cables, port type, motherboard (integrated video)	Video drivers in Windows	Video BIOS, BIOS configuration of video type, boot priority
Audio	Sound card, microphone, speakers , speaker and microphone cables, CD analog and digital cables to sound card, motherboard (integrated audio)	Audio drivers in Windows	BIOS configuration of integrated audio
Mouse and pointing device	Mouse or pointing device, serial or mouse port, USB port	Mouse driver in Windows	BIOS port configuration, USB legacy configuration
Keyboard	Keyboard, PS/2 or USB port	Keyboard driver in Windows	BIOS keyboard configuration, USB legacy configuration
Storage	Drives, data cables, power connectors, USB, IEEE-1394 or SCSI cards, or built-in ports	Storage drivers in Windows	BIOS drive configuration, BIOS configuration of built-in USB or other ports
Power	Power supply, splitters, fans	Power-management software (Windows)	BIOS power-management configuration
CPU	CPU, motherboard	System devices	BIOS cache and CPU configuration
RAM	RAM, motherboard	(none)	BIOS RAM configuration
Network	NIC, motherboard, USB port (for USB devices)	Network configuration files and drivers	BIOS PnP and power management, BIOS configuration of integrated network port or USB port
Modem	Modem, motherboard or serial port or USB port	Modem drivers, application	BIOS PnP, power management, BIOS port configuration

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

If you don't record the current configuration of the system's hardware and software before you start the troubleshooting cycle, you will not be able to reset the system to its previous condition if your first change doesn't solve the problem.

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.

No matter how concerned your client is and no matter how heavy your workload, change only one before you retest the system.

"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

Rather than give away, sell, or discard working video cards, hard disks, and other components you have replaced with faster, bigger, and better upgrades, keep at least one of each item to use as a replacement for testing purposes or as a backup in case the upgrade fails.

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.