Troubleshooting Methodology

Week of 2026-10-06 · Download .docx

Objectives

Troubleshoot common network connectivity issues using systematic diagnostic steps.
Apply the CompTIA seven-step troubleshooting methodology.
Use command-line tools including ping, tracert, ipconfig, nslookup, and netstat.
Resolve common Windows issues using sfc, DISM, chkdsk, and Device Manager.

Key terms

Troubleshooting methodology: CompTIA's seven-step process: identify → theorize → test → plan → implement → verify → document.
Occam's Razor: The simplest explanation is most likely correct — check simple causes before complex ones.
ping: ICMP utility that tests reachability and measures round-trip time to a host.
tracert / traceroute: Shows each router hop between your machine and a remote destination with latency.
ipconfig: Windows command that displays current IP address, subnet mask, gateway, and DNS server.
nslookup: Tests DNS resolution by querying a name server for a hostname or IP.
netstat: Displays active connections, listening ports, and protocol counters.
sfc /scannow: System File Checker — scans and restores corrupted Windows system files.
DISM /RestoreHealth: Repairs the Windows Component Store that sfc uses for replacement files.
chkdsk: Check Disk — scans and repairs file system errors and bad disk sectors.
BSOD stop code: Hexadecimal error code on a Blue Screen of Death that identifies the crash type.
Safe Mode: Minimal Windows boot loading only essential drivers — isolates driver/software conflicts.
Device Manager: Windows tool showing installed hardware and driver status with error icons.
Startup Repair: Windows Recovery Environment tool that automatically fixes common boot problems.
Roll Back Driver: Device Manager option to revert a device driver to its previously installed version.

The concept

Troubleshooting is a systematic discipline. Random changes and guesswork waste time and can make problems worse. The CompTIA seven-step methodology provides a repeatable framework applicable to any IT problem.

Step 1: Identify the problem. Gather information from the user — what happened, when, and under what conditions. Reproduce the issue to observe it firsthand. Step 2: Establish a theory. Using Occam's Razor, hypothesize from simplest cause (cable unplugged, wrong password) to most complex. Step 3: Test the theory. If confirmed, proceed; if not, revise and try again. Step 4: Plan a course of action and consider escalation or change management requirements. Step 5: Implement the solution. Step 6: Verify full system functionality — confirm the fix works and has not caused new problems. Step 7: Document findings, actions, and outcomes for future reference and knowledge base articles.

Network troubleshooting follows a layered sequence matching the OSI model. First ping 127.0.0.1 (loopback) — if this fails, the local TCP/IP stack is broken. Then ping the default gateway — confirms local routing. Then ping an external IP like 8.8.8.8 — confirms internet connectivity. Then ping a hostname like google.com — if IP ping works but name ping fails, the problem is DNS, not the network. Use ipconfig /release and /renew to request a new DHCP lease when a device has a 169.254.x.x APIPA address. Use ipconfig /flushdns to clear stale cached name records.

Windows-specific troubleshooting has dedicated tools for each layer. sfc /scannow verifies and replaces corrupted OS system files. If sfc reports it cannot repair files, run DISM /Online /Cleanup-Image /RestoreHealth first to repair the Component Store, then re-run sfc. chkdsk /f /r repairs file system errors and scans for bad sectors on the disk volume. A BSOD stop code (e.g., IRQL_NOT_LESS_OR_EQUAL) identifies the class of kernel error — search it to find the responsible driver or component. Device Manager uses a yellow exclamation mark to flag devices with driver problems; Roll Back Driver restores the previous working driver version after a bad update.

Worked examples

Example 1: A user reports they can browse the internet but cannot access the company intranet at intranet.corp.com. You ping 8.8.8.8 — success (internet routing OK). You ping intranet.corp.com — timeout. You ping the intranet server's IP directly — success. The problem is isolated to DNS not resolving the internal hostname. You run ipconfig /flushdns; the cached stale record is cleared and the hostname resolves correctly.

Example 2: After a Windows Update, a user's graphics tablet stops working. Device Manager shows a yellow (!) on the tablet under Human Interface Devices. You right-click > Properties > Driver tab > Roll Back Driver. Windows restores the previous driver version and the tablet works immediately. This is a classic 'bad driver from Windows Update' scenario — Roll Back Driver is the targeted fix.

Common mistakes

Jumping straight to hardware replacement before testing software and configuration — expensive and often unnecessary.
Pinging a hostname to test connectivity when the real symptom might be DNS failure, not network failure.
Skipping documentation — the next technician (or your future self) will need to know what was changed and why.
Running DISM after sfc instead of before — if the Component Store is corrupt, sfc cannot pull replacement files.
Using chkdsk to fix OS file corruption — chkdsk fixes disk and file system errors; sfc fixes OS file integrity.

Self-check

Try each one before you look. A miss here costs nothing and tells you exactly what to reread.

1. In the CompTIA troubleshooting methodology, what is Step 1?

2. You ping 8.8.8.8 successfully but cannot browse google.com. What is the likely problem?

3. Which tool repairs the Windows Component Store so sfc can draw replacement files?

4. A yellow (!) in Device Manager indicates:

5. Which command clears the local DNS resolver cache?

Canvas is the official record. This companion enhances the PGCC curriculum; it does not replace it. Last name and class year only. Students with a 504 plan or IEP: your accommodations apply.

↑ Back to top