A structured methodology

Hardware faults tempt people to start swapping parts at random. That wastes time and parts, and when the problem disappears nobody knows which change fixed it. CompTIA's A+ troubleshooting method has six steps. It was a tested objective in 220-1101; in 220-1201 CompTIA keeps it as a recommended best practice but no longer tests it. The general idea of a troubleshooting method is explained under Troubleshooting in Networking, which uses the seven-step Network+ variant. The six steps, in the 220-1201 wording:

  1. Identify the problem. In practice: gather information from the user, ask what changed (by the user, in the environment or in the infrastructure), and back up the data before making changes.
  2. Establish a theory of probable cause (question the obvious; research the knowledge base or the internet, if applicable).
  3. Test the theory to determine the cause. Once the theory is confirmed, determine the next steps to resolve the problem. If it is not confirmed, establish a new theory or escalate.
  4. Establish a plan of action and implement the solution. Refer to the vendor's instructions for guidance.
  5. Verify full system functionality and, if applicable, implement preventive measures.
  6. Document findings/lessons learned, actions, and outcomes.

Throughout, consider corporate policies, procedures and the impact on the user before you change anything: a replacement disk may need approval, and a repair may need to wait until the user has saved their work.

Start with the simple things

"Question the obvious" is step 2 for a reason. A large share of hardware tickets end with a cable, a switch or a loose connection:

  • Power: is the outlet live (try another device), is the power strip switched on, is the switch on the back of the power supply on, is the laptop's charger light on?
  • Cables: firmly plugged in at both ends, into the right port? Swap in a known-good cable.
  • Reseat: with the power off and electrostatic discharge (ESD) precautions taken, remove and reinsert memory modules, expansion cards and internal cables. Oxidized or slightly lifted contacts are common, especially after a computer has been moved.
  • Minimal configuration: disconnect everything that is not needed to start — extra drives, cards, Universal Serial Bus (USB) devices — and add them back one at a time.
  • Known-good parts: swapping a suspect part for one that is known to work is one of the fastest tests there is.

Before opening a case, read Safety and Handling: unplug the power cord and protect the parts against electrostatic discharge.

Problems at start-up

When a computer "does not start", the first question is: how far does it get? The start-up — power, the power-on self-test (POST), the boot device, the operating system (OS) — is a chain (see the boot sequence), and the step where it stops points to the cause.

Start-up triage in four questions. Does it power on? If not, check the outlet, cable, power supply and power switch. Does POST pass? If not, read the beeps or LEDs and check memory, CPU and board. Is there a picture? If not, check the monitor, cable, input and graphics. Does the operating system start? If not, check the boot order, disk and bootloader. Powers on? POST passes? Picture? OS starts? yes yes yes no no no no outlet, cable, PSU, switch beeps or LEDs: RAM, CPU, board monitor, cable, input, graphics boot order, disk, bootloader
Four questions narrow a "dead computer" down to one part of the chain before any part is replaced.
Symptom Likely causes What to check
No power: no fans, no lights No power at the outlet, power cable (in the UK also a blown fuse in the plug), power supply unit (PSU) switch or failure, front-panel power button cable Another outlet and cable; PSU switch; PSU tester; the power button header on the motherboard
Fans spin, but no POST: no picture, no beeps Memory not seated, central processing unit (CPU) power connector (the 4- or 8-pin connector near the socket) not plugged in, CPU not supported by the firmware, failed board or CPU Diagnostic light-emitting diodes (LEDs); reseat memory, try one module; check all power connectors; minimal configuration
Beeps or diagnostic LEDs/codes POST found a failing component Look up the code in the board's manual
Computer runs, but no display Monitor off or on the wrong input, loose or faulty cable, monitor connected to the board's outputs while a graphics card is installed, graphics card power not connected Monitor input and power; another cable and monitor; connect to the graphics card's outputs
"No boot device" or "operating system not found" Wrong boot order, USB stick left in, drive not detected, damaged bootloader Remove USB storage; boot order and drive list in the firmware setup; data and power cables of the drive
Date and time wrong after being unplugged CMOS (complementary metal-oxide-semiconductor) battery empty Replace the coin cell, reset date and time

Beep codes and diagnostic codes

A beep code is a pattern of short and long beeps that the firmware plays through a small speaker when POST finds a problem it cannot show on screen, for example because the memory or graphics does not work. The patterns are not standardized: they differ per firmware vendor and even per board model, so the same pattern can mean "memory error" on one computer and "graphics error" on another. Always look the pattern up in the manual of that specific board.

Many current desktop boards have no speaker at all. Instead they show the stage where the start stopped with small diagnostic LEDs (CPU, DRAM, VGA, BOOT) or a two-digit code display; many laptops blink a status LED in a pattern. The idea is the same: the firmware reports how far it got.

Problems while running

Symptom Likely causes What to check
Random shutdowns or reboots, especially under load Overheating (dust, a failed fan, dried-out thermal paste), a failing or undersized PSU, faulty memory Temperatures in firmware or monitoring software; clean dust and check fans; event log; test the PSU and memory
Blue screen / stop error Faulty driver, memory errors, failing storage, overheating The stop code; recent driver or hardware changes; memory test; drive health
Slow performance Thermal throttling, too little random-access memory (RAM, constant paging), a failing drive retrying reads, a hard disk where a solid-state drive (SSD) is expected Temperatures and clock speed under load; memory use and disk activity in Task Manager; drive health
Loud fan, rattling or whining Dust, a worn fan bearing, a cable touching a fan Clean or replace the fan; route cables away
Burning smell, smoke A failed component, often in the PSU Power off and unplug immediately; find the source by look and smell; replace the part, never repair a PSU
Intermittent USB devices Not enough power (unpowered hub, bus-powered drive), a worn port or cable, power-saving settings, drivers Another port (preferably directly on the computer), a powered hub, another cable; USB power management settings
Swollen battery, bulging case, capacitors with domed tops Battery or capacitor failure Stop using the device; replace the part; handle swollen batteries as described in Safety and Handling

Stop errors

A stop error is a crash in which Windows halts completely because it detected a condition it cannot recover from safely, such as corrupted memory or a failing driver. It is better known as the blue screen of death (BSOD); Linux and macOS have the equivalent kernel panic. The screen shows a stop code such as MEMORY_MANAGEMENT or WHEA_UNCORRECTABLE_ERROR (a hardware error reported by the Windows Hardware Error Architecture), and Windows restarts.

One stop error is a data point; a pattern is a diagnosis. Write down the stop code, check what changed recently (a new driver, new memory), and look for the crash in the event log. Windows saves memory dumps (by default small dumps in C:\Windows\Minidump) that tools can analyze to name the driver involved. Stop errors with different codes every time often point to hardware — memory, overheating or power — rather than one bad driver.

Storage problems and S.M.A.R.T.

Failing storage deserves its own attention because the data is at stake. Typical signs: a hard disk that clicks or grinds, very slow file access, files that cannot be read, repeated disk errors in the event log, or a warning at start-up.

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) is the health monitoring built into hard disks and SSDs. The drive keeps counters of its own condition — reallocated sectors, read errors, temperature, power-on hours, and for SSDs the percentage of write endurance used — and reports whether any value has crossed its failure threshold. Many firmware setups warn at start-up when a drive reports a failing state. On Linux, smartctl from the smartmontools package reads it:

sudo smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-25-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

A failing drive reports FAILED! instead, followed by Drive failure expected in less than 24 hours. SAVE ALL DATA. "PASSED" does not guarantee a healthy drive: smartctl -a shows all counters, and on Serial ATA (SATA) drives rising values for reallocated sectors (attribute 5) or pending sectors (197) are early warnings even while the overall result still passes. Non-Volatile Memory Express (NVMe) drives report Percentage Used, Media and Data Integrity Errors and Critical Warning instead. On Windows, PowerShell shows a summary per drive:

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus
FriendlyName   MediaType HealthStatus
------------   --------- ------------
NVMe SSD 1TB   SSD       Healthy
SATA HDD 2TB   HDD       Warning

Hardware tools

Multimeter

A multimeter measures voltage, resistance and current, and usually continuity (whether a wire or fuse conducts). Technicians use it to check the low-voltage outputs of a power supply, test a cable or fuse for continuity, or confirm that a laptop charger delivers its rated voltage.

A desktop power supply delivers direct current at a few fixed voltages ("rails"), and the Advanced Technology eXtended (ATX) power supply design guide allows each only a small deviation. Comparing measured values with those limits:

# Tolerances from the ATX power supply design guide:
# +12 V, +5 V, +3.3 V and +5 V standby within 5%; -12 V within 10%.
RAILS = {
    "+12 V": (12.0, 0.05),
    "+5 V": (5.0, 0.05),
    "+3.3 V": (3.3, 0.05),
    "+5 VSB": (5.0, 0.05),
    "-12 V": (-12.0, 0.10),
}
readings = {"+12 V": 11.31, "+5 V": 5.04, "+3.3 V": 3.35,
            "+5 VSB": 5.02, "-12 V": -11.90}

for rail, (nominal, tolerance) in RAILS.items():
    low, high = sorted([nominal * (1 - tolerance), nominal * (1 + tolerance)])
    value = readings[rail]
    status = "ok" if low <= value <= high else "OUT OF RANGE"
    print(f"{rail:<7} {value:6.2f} V   allowed {low:7.3f} to {high:7.3f}   {status}")
+12 V    11.31 V   allowed  11.400 to  12.600   OUT OF RANGE
+5 V      5.04 V   allowed   4.750 to   5.250   ok
+3.3 V    3.35 V   allowed   3.135 to   3.465   ok
+5 VSB    5.02 V   allowed   4.750 to   5.250   ok
-12 V   -11.90 V   allowed -13.200 to -10.800   ok

A +12 V rail that sags to 11.3 V, especially under load, explains random shutdowns: the CPU and graphics card draw most of their power from it. The fix is a new power supply, not a repair.

PSU tester, POST card and others

  • A PSU tester is a small device with sockets for the 24-pin motherboard connector and the other PSU connectors. It switches the power supply on and shows whether each voltage is within range — quicker and safer than a multimeter. It tests with little or no load, so a supply that sags only under load can still pass.
  • A POST card is a diagnostic card, plugged into an expansion slot, or into an LPC (Low Pin Count) or M.2 debug connector on laptops, that displays the progress codes the firmware writes during POST as hexadecimal numbers. The last code shown tells you at which step the start-up stopped; its meaning is looked up in the firmware vendor's code list. Many current boards have the same display built in.
  • A loopback plug is a connector that routes a port's transmit lines back to its receive lines, so the port can test itself without another device. An RJ45 loopback plug makes a network port's link light come on and lets diagnostic software test the network card; loopback plugs also exist for serial and fiber ports.
  • A cable tester checks every wire of a network cable for continuity and correct pin order (see Cabling and the Physical Layer).
  • An infrared thermometer or a thermal camera shows hot spots without contact: a chip or voltage regulator that runs far hotter than its neighbors, a blocked vent.

Software tools

  • Event logs. Windows Event Viewer records hardware problems in the System log: disk errors, WHEA-Logger hardware errors, and Kernel-Power event 41 when the computer restarted without shutting down cleanly — typical for power loss, overheating or a crash. On Linux, journalctl and dmesg show kernel messages about hardware.
  • Memory tests. Windows Memory Diagnostic (mdsched.exe) or a bootable tool such as MemTest86+ writes and reads patterns across all memory. Let it run for at least one full pass; a single error means a module (or its settings) is faulty.
  • Drive health. S.M.A.R.T. through smartctl, Get-PhysicalDisk or the drive vendor's tool, as shown above.
  • Temperatures and clock speeds. The firmware setup shows them at idle; monitoring software shows them under load, which is when thermal problems appear.
  • Vendor diagnostics. Most PC and laptop brands include a built-in diagnostic that runs from the firmware or a boot menu, and produces a code that their support desk accepts for a warranty claim.

Documenting and escalating

The last step of the method is easy to skip and expensive to forget. A good ticket records the symptom in the user's words, what you tested and what the results were (including the tests that showed nothing), the cause, what you changed — with part and serial numbers — and how you verified the fix. That record helps the next technician, shows patterns (the third failed power supply in the same model), and supports warranty claims.

Escalate when the problem is outside your knowledge, your permissions or your time budget: to a second-line colleague, to the vendor's support, or through a warranty process in which the vendor issues a return merchandise authorization (RMA) for the faulty part. Escalating is not failing: passing on a well-documented ticket early is better than working on a problem for hours alone. Check the warranty status before you open a device, because opening it can void the warranty on some equipment.