Troubleshooting

IT Troubleshooting: Methodology, Diagnostics, and Common Fixes

Effective troubleshooting follows a consistent process: gather information, identify the scope of the problem, form a hypothesis about the cause, test that hypothesis with the minimum change needed to confirm or deny it, and document what you did and what you found. Systematic elimination of possibilities is faster than random changes and prevents making things worse.

The troubleshooting methodology

The CompTIA troubleshooting model is a practical framework: identify the problem (gather symptoms, ask what changed recently, establish the timeline), establish a theory of probable cause (consider the most likely explanations first), test the theory, establish a plan of action, implement the solution, verify functionality, and document the outcome. The most important step is asking what changed: most problems are caused by something that changed recently, whether a software update, a configuration edit, a new device, or a failing hardware component.

Scope is the second key question. Is only one user affected or everyone? Is it one machine, one subnet, or the whole building? Is it one application or all applications? Narrowing scope points to the layer and component where the problem lives. A problem affecting every user but only when accessing one server is almost certainly a server problem or a problem on the path to that server, not a client-side issue.

Network connectivity troubleshooting

Start from the bottom of the OSI model and work up. Physical layer: is the cable connected? Are the link lights on the switch port lit? Swapping a cable is the fastest test. Data link: does the device have a valid IP address (ipconfig on Windows, ip addr on Linux)? A 169.254.x.x address means DHCP failed. Network layer: can the device ping its default gateway? Can it ping an external IP address (8.8.8.8 is Google's DNS and a useful test target)? Transport and application: can the device connect to the specific service that is failing?

ping tests ICMP reachability between two points. traceroute (tracert on Windows) shows every hop on the path and where packets stop. nslookup and dig test DNS resolution. netstat -an shows listening ports and active connections. These four tools answer the most common network questions. For encrypted connections, remember that a firewall or security group might permit ICMP but block TCP port 443, so a successful ping does not mean HTTPS is working.

Hardware diagnostics

Hardware problems present in a small number of ways: failure to POST (the system does not start or shows error codes), random reboots or blue screens, file system errors, and slow performance. A failure to POST with beep codes or LED indicators points to a specific component; the motherboard documentation maps the codes. Random reboots under load suggest overheating (check CPU temperatures with a monitoring tool) or power supply problems (test with a known-good PSU). Memory errors cause the most unpredictable symptoms: random crashes, file corruption, and different errors each time. Run a memory test (memtest86+) overnight to rule out RAM.

Disk problems show up in SMART data before drives fail completely. Use a SMART monitoring tool (CrystalDiskInfo on Windows, smartmontools on Linux) to check reallocated sectors, pending sectors, and uncorrectable errors. Elevated counts in these fields indicate impending failure; back up immediately and plan replacement. For performance problems, check whether the drive is being used as a disk cache for insufficient RAM (constant disk activity when no disk-intensive task is running) or whether the SATA/NVMe connection is operating below its rated speed.

Software and OS troubleshooting

Software problems fall into two categories: problems that existed from the beginning (configuration or installation errors) and problems that developed over time (data corruption, software updates, resource exhaustion). For configuration errors, the error message is the starting point; read it carefully before searching for it because subtle differences in the message often point to different root causes. Check application logs, which on Windows are typically in Event Viewer and on Linux in /var/log or via journalctl.

Resource exhaustion is a common and underdiagnosed cause of software problems. Disk full errors cascade: many applications fail in unexpected ways when their working directory or log directory fills up. Similarly, running out of RAM causes swapping, which slows everything and can starve the OS itself. A quick check of disk space (df -h on Linux, the Properties dialog or Get-PSDrive in PowerShell on Windows) and memory usage should be early steps in any software slowdown diagnosis.

Key concepts

+ Ask what changed: Most problems have a recent change as their cause; identifying it narrows the search dramatically.
+ Establish scope: One user, one machine, or everyone? Scope points to the layer where the problem lives.
+ Work the OSI stack: For network problems, start at the physical layer and work up; confirm each layer before moving to the next.
+ Test one thing at a time: Changing multiple variables simultaneously makes it impossible to know which change fixed the problem.
+ Check logs: Event Viewer on Windows, journalctl and /var/log on Linux; logs often name the exact error before you do.
+ Document everything: Record what you tried, what you found, and what fixed it; the next occurrence is faster with a record.

Frequently asked questions

A user says 'the internet is not working' - where do you start?

First verify the complaint is accurate and scope it: is it all internet access or one site? Is it one device or all devices? Check that the device has a valid IP address (not 169.254.x.x). Try pinging the default gateway to confirm local network connectivity. Try pinging 8.8.8.8 to confirm routing works without DNS. Try pinging google.com to test DNS. This four-step test isolates whether the problem is physical, DHCP, routing, or DNS, and each step points to a specific fix.

A Windows PC shows a Blue Screen of Death - what should I check?

Note the stop code shown on the screen or in Event Viewer (look under Windows Logs > System). Common codes: MEMORY_MANAGEMENT and PAGE_FAULT_IN_NONPAGED_AREA point to RAM or driver issues; run memtest86+. DRIVER_IRQL_NOT_LESS_OR_EQUAL and DRIVER_POWER_STATE_FAILURE often indicate a driver update needed or a faulty driver. If it started after a Windows Update, consider rolling back the update. If it is random with no pattern, test RAM and check storage SMART data.

How do you approach a problem when you have no error message?

Start with what you can observe: when does the problem occur (always, intermittently, under load, at a specific time)? What changed recently? What does the user report as the symptom? Then look for indirect evidence: check system event logs for warnings or errors around the time of the problem, check resource utilization (CPU, memory, disk I/O), and check for any recent software updates or configuration changes. Without an error message, establishing a reliable way to reproduce the problem is the most important step.

When should you escalate rather than keep troubleshooting?

Escalate when you have exhausted your knowledge or access, when the problem is impacting a critical system and time is essential, when the fix requires permissions or physical access you do not have, or when you have ruled out everything in your tier and the problem clearly requires specialized expertise. Document everything you have already tried before escalating so the next person does not repeat your steps.