220-1101 Hardware and Network Troubleshooting Study Guide for the CompTIA A+ Core Series Exam

General Information

When hardware and networks work well, it’s a beautiful thing. But we know this is not always the case and, as an IT support professional, you will be depended upon to fix whatever goes wrong. Any device or network issue will fall within your domain. This is why hardware and network troubleshooting is the most emphasized area on the CompTIA A+ 1101 test, with 29% (nearly one-third) of the questions pertaining to it. It is important to note that all the questions about hardware and network troubleshooting will begin with a scenario.

Best Practice Methodology

Best practice methodology refers to the use of basic structured principles that should be followed when approaching a troubleshooting situation. While individuals may approach troubleshooting differently, certain basic principles remain constant: create a backup, prioritize tasks, and document the process. Note: Questions regarding this section of the exam will come in the form of scenarios.

Corporate Policies, Procedures, and Impacts

Every corporate enterprise has differing policies and procedures. Always consider corporate policies, procedures, and potential impacts before you begin troubleshooting.

1. Identify the Problem

The first step when troubleshooting an issue is to identify the problem. Technical problems with computer systems generally occur in one (or more) of four areas: hardware, the operating system, software, and the user. It is vital to accurately identify the problem before taking action.

• Gather information—To properly identify a problem, begin by gathering information from the user and the computer system in question. When gathering information from the user, ask questions to clarify the problem. Clarifying the issue will give you a starting point for further investigation. After questioning the user, examine the device to determine what is working and what is not. Check for common issues such as power problems or issues resolved upon reboot. Look into systems logs or application logs for information. Is the issue a hardware problem or a software problem?

• Inquire about changes—Consider all the changes that could affect the user (e.g., network, computer, power issues, external connection, user account) and how those changes can be involved in the problem. As an example, let’s say the network team worked over the weekend performing an upgrade to the infrastructure (switch replacement) and neglected to plug all the cabling back into the switch (as simple as a cable falling behind the wiring channel and being missed). The user might have been the one missed and now they cannot authenticate to the network, access their files, print to the network printer, and, therefore, cannot perform common functions. These things happen daily and other teams can be conducting changes without regard to the effect on employees.

2. Create a Theory of Probable Cause

Keep it simple. Always question the obvious and don’t assume something isn’t relevant. You might think it is common sense to be plugged into the network, but the user might not know this. Using your questioning ability, develop a theory (or two) regarding what the problem might be. When developing a theory, remember to eliminate possible theories as well if they do not fit the scenario.

• External or internal research—Utilize research resources, which can include internal and external resources. Check previous service documentation within the company, refer back to the device manual, and check for potential theories using online forums and search engines. The internet, when utilized properly, can be extremely helpful for troubleshooting problems.

3. Test the Theory/Determine the Cause

When you have your theory developed, you need to test it. On a time-sensitive issue, or if you know 100% that the theory is valid, you can implement it based upon corporate policies and/or procedures. In a perfect world, you would be able to replicate the issue within a testing (or laboratory) environment for verification. This isn’t always the case and you should be ready to test your theory at a moment’s notice. When testing a theory, begin with the most obvious and simple theories first, such as checking the power supply or ensuring cables are properly seated, before moving onto more complicated theories.

• If theory is confirmed, determine next steps—Only test one possible solution at a time and only make one change at a time. Sounds like a lengthy process? It is, but if you implement multiple changes in one process, how do you know which one worked and which one didn’t? Remember, keep it simple. If your theory is confirmed, then you can skip to the plan of action to implement your theory. If not, then it’s back to testing again. No worries, proper troubleshooting is an art.

• If theory is not confirmed, establish new theory or escalate—You’ve tested your theory and the problem still exists. Step back and take a look at your theory to see what other avenues are available and develop a working theory regarding the next possible solution. If you have exhausted all your potential theories, it may be time to escalate the problem.

4. Create a Plan of Action

Always remember: Your company’s policies and procedures take precedence and should be in the forefront prior to acting on any plan. The conclusion that you make might affect the whole company, but that might also be needed depending on the breath of the issue. Does correcting the issue require downtime for the company or just a single computer? Can that be scheduled around the users’ workday? Does it need to happen immediately? These are all questions that should be included in your plan of action.

• Vendor instructions—When creating a plan of action, remember to take into account vendor instructions. Vendors often provide documented fixes to identified issues, which should be considered.

Verify System Functionality

Once the issues have been resolved or appear to be resolved, verify full functionality of the problem system. Remember to verify full system functionality and do not focus strictly on the problem system. A fix to one system or component may cause issues with another system or component.

Document Findings, Actions, and Outcomes

Documentation! We can’t express how important it is for issues to be fully documented. Everything that you have done from the moment the user contacted you to the moment the user was back online, such as indications, findings, actions, outcomes, scenarios, etc., must be documented. Your company should have a repository to keep this information safe. It should also be possible to share among your peers in the event the same type of issue arises in the future.

Problems with Motherboards, RAM, CPU, and Power

There are many different situations that can arise when various types of hardware components start failing. You must be able to troubleshoot common problems through a scenario.

Common Symptoms

The motherboard, RAM, CPU, and power supply are the most critical components to a computer system. Problems with these components may have the same or similar symptoms. The list below covers general troubleshooting guidelines and causes of common symptoms.

Power-on Self-Test (POST) Beeps

The power-on self-test (POST) is a built-in diagnostic program in the BIOS/UEFI. When an error in the POST occurs, the computer performs a series of beeps, called the beep code. To identify the issue, listen to the beep code and refer to the vendor documentation to match the beep code with the corresponding error. The cause of these beeps could be problems with BIOS configuration or hardware.

Proprietary Crash Screens

Proprietary crash screens are operating system-specific error messages that occur when there is a potentially fatal error in the system. The most common proprietary crash screens are the Windows blue screen of death (BSOD) and the macOS rotating pinwheel. Common causes of these crash screens are memory issues, which may cause application crashes or error messages.

Black Screen

A black screen is indicative of no video output. Common causes of a black screen include problems with the video card, cabling, or the screen itself. Remember that many motherboards have the video card built in, which may indicate an issue with the motherboard itself. In this case, you can attempt to connect an external video card that, once connected, in most cases will disable the onboard video card.

No Power

Power outlet or power supply issues are usually the cause of this. When troubleshooting, begin by testing and replacing the easiest and most obvious components first before removing and replacing the power supply.

Sluggish Performance

Sluggish performance is one of the more difficult problems to troubleshoot. Common causes include low memory, low hard drive space, failing primary components, bad applications, too many applications, or malware. A good place to start when troubleshooting on a Windows OS is to view memory usage in Task Manager, which provides real-time statistics on the CPU, RAM, hard drive, and network connection.

Overheating

Problems with the fan, heat sink, dust accumulation, or something blocking the air circulation can all cause a device to overheat. Examine the device for impediments to the cooling mechanisms, such as excess dust or improper placement for optimal ventilation. Compressed air is one way to clean excess dust accumulation, but ensure that you are blowing away from the internal components of the computer rather than further into the device.

Burning Smell

A burning smell coming from a computer system is never a good thing. If you detect a burning smell, shut down the device immediately and examine it for potential culprits. Look for melted plastic and burn marks on circuit boards. Replace affected components and monitor the new component for failure. A component that fails too quickly may be an indicator of a power supply issue.

Intermittent Shutdown

An intermittent shutdown is typically a result of components overheating and failing. Intermittent shutdowns may also be caused by a bad hardware installation or improper motherboard connection.

Application Crashes

Application crashes are often an indicator of memory-related issues, such as failing memory or not enough memory available to run the application properly.

Grinding Noise

Grinding noises can only originate from moving components within the computer, such as the HDDs, fans, and optical drives. This fact eliminates all non-moving components within the device. Whirring sounds tend to originate from fans, while clicking or squealing sounds often come from the HDD. Optical drive noises are the simplest to diagnose.

Capacitor Swelling

Capacitors store electricity on the motherboard. When a capacitor fails, they tend to swell and produce a brownish-red residue that may seep. This phenomenon is referred to as a distended capacitor or capacitor swelling. Two options to resolve this issue include replacing the motherboard or replacing the capacitor, which requires specialized training.

Inaccurate System Date/Time

Inaccurate system date/time is most likely an indication of a bad CMOS battery. The CMOS battery is responsible for retaining the computer’s settings when it is powered off and is located on the motherboard. When the CMOS battery fails, the computer will be unable to retain its BIOS settings.