1.2Basic troubleshooting (hardware & software)
The essentials in 30 seconds
- Troubleshooting is a method, not a set of recipes: reproduce, isolate, test a hypothesis, fix, document.
- A problem that follows the user is more likely software; a problem that stays on the machine is more likely hardware.
- Change only one thing at a time: otherwise you cannot know what actually had an effect.
Rolling mini-case — Sofiane and the workstation that no longer connects to Wi-Fi
At the support desk of the SME distributor in Algiers, Sofiane gets a call: an assistant's PC no longer connects to Wi-Fi. He applies the method instead of tinkering. He reproduces the problem (the user fails on every attempt), then isolates: the other office workstations connect, so the fault is local to this machine, not the box. He forms a hypothesis — a corrupted Wi-Fi driver or a damaged network profile — and tests it by changing only one thing at a time: forget the network, then reinstall the driver. The Wi-Fi comes back. Sofiane documents the cause and the solution in the ticket, even though the fix seemed simple. He keeps in mind: isolating before acting avoids "fixing" what isn't broken.
Standalone case for this section: it returns in the course, the diagram, the script and the 48h challenge of section 1.2.
1. A method, not recipes
Effective troubleshooting follows a repeatable method: reproduce the problem, isolate it (hardware or software?), form a hypothesis, test it by changing only one thing at a time, fix it, then document it. Avoid "tinkering" that changes ten settings and no longer knows which one solved — or broke — what. Sofiane applies the method even on an incident that looks trivial.
2. Hardware or software?
A few signals point the way: a problem that follows the user (same issue on another PC with their account) is more likely software; a problem that stays on the machine (noise, overheating, screen) is more likely hardware. Testing with another cable, another account, or in Safe Mode helps isolate the cause. Sofiane always isolates before replacing anything.
3. The basics
Many faults are solved with the fundamentals: restart (clears memory and restarts services), check the cables and power, check disk space, read the exact error message, consult the Event Viewer. Restarting is no joke: it genuinely resolves a large share of incidents. Sofiane always ends by noting the cause and the solution, even for a simple restart.
🔎 Concrete example — 🔎 Concrete example — "The PC no longer connects to Wi-Fi"
Sofiane's application of the method:
Reproduce : yes, on every attempt
Isolate : other PCs connect → problem local to this workstation
Hypothesis: corrupted Wi-Fi driver or network profile
Test : forget the network + reinstall the driver
Document : ticket + cause + solutionReading: since the other workstations work, the fault is local — you target the workstation, not the box.
Lesson: isolating before acting avoids "fixing" what isn't broken.
Section vocabulary
- Isolating a fault
- Reducing the possible causes by testing one element at a time.
Simple example: Sofiane tests another cable then another account to pin down the cause.
What it is not: changing ten settings at once without knowing what has an effect.
Reflex: isolate before concluding.
- Safe Mode
- Minimal Windows startup, useful for ruling out third-party software and drivers.
Simple example: Sofiane starts in Safe Mode to see whether a third-party driver is blocking.
What it is not: a normal startup that loads all the services.
Reflex: rule out drivers → Safe Mode.
- Event Viewer
- A Windows log that records system errors and warnings.
Simple example: Sofiane reads the exact error there before proposing a fix.
What it is not: a simple on-screen message, with no detailed log.
Reflex: look for the cause → Event Viewer.
- Hypothesis
- A supposed cause that you test before keeping or ruling it out.
Simple example: Sofiane suspects a corrupted network profile and checks it.
What it is not: concluding "hardware" without having tested anything.
Reflex: a hypothesis is tested, one thing at a time.
- Reproduce
- Make the problem appear again on purpose in order to study it.
Simple example: Sofiane reproduces the connection failure on every attempt.
What it is not: acting on a symptom you have not managed to see.
Reflex: reproduce the problem first.
In practice — In practice — Running a diagnosis
- Facing a fault, write down the symptom and the error message precisely.
- Determine whether the problem follows the user or stays on the machine.
- Test one hypothesis at a time (cable, account, Safe Mode).
- Note the cause and the solution in the ticket, even if it was "just a restart".
Step-by-step script — diagnose like Sofiane (5 min)
1) Describe the symptom and copy the exact error message. 2) Reproduce the problem to see it with your own eyes. 3) Isolate: does the issue follow the account (another PC) or stay on the machine (another cable, Safe Mode)? 4) Form a hypothesis and test it by changing only one thing. 5) Fix it, have the user confirm, then document cause and solution in the ticket.
Restarting and reading the exact error resolve a large share of incidents: start there.
Copy-paste template — my diagnosis sheet
Exact symptom: ___
Error message: ___
Reproduced? yes / no — how: ___
Follows the user or stays on the machine: ___
Hypothesis tested (only one): ___
Test result: ___
Fix applied: ___
Documented in the ticket: yes / noSoftware fault
Sofiane isolates a corrupted network profile: the problem follows the account and disappears on another workstation.
Hardware fault
Sofiane suspects a faulty cable: by changing it, the problem disappears — it is indeed hardware.
Safe Mode
Sofiane starts in Safe Mode to rule out third-party drivers before deciding.
Document
Whatever the result, Sofiane notes the cause and the solution in the ticket, even for a restart.
✓ Best practices
- Change only one thing at a time.
- Read the exact error message before acting.
- Always document the cause and the solution.
✗ Common pitfalls
- Modifying ten settings at once.
- Skipping the "reproduce" step.
- Concluding "hardware" without having isolated the software.
Key takeaways
- Troubleshooting is a method: reproduce, isolate, test, fix, document.
- Problem that follows the user = software; one that stays on the machine = hardware.
- One variable at a time to know what has an effect.
- Restarting and reading the exact error resolve a large share of cases.
48h challenge — apply it tomorrow
Take a recent incident and fill in Sofiane's diagnosis sheet: exact symptom, isolation (does it follow the user or stay on the machine?), one single hypothesis tested, fix and cause noted. In one sentence, write what you could have broken by changing too many things at once.
- I can diagnose a fault with a repeatable method.
- I can tell a software problem from a hardware problem.
- I document the cause and the solution in the ticket.
Frequently asked questions
Why does "restarting" work so often?
Restarting clears memory, closes stuck processes and restarts services in a clean state. Many incidents come from a corrupted transient state that a restart wipes away.
How do you know it's hardware?
By isolating: test the same account on another workstation, another cable/screen, Safe Mode. If the problem disappears when you change the hardware, it is hardware; if it follows the account, it is software.
What is the golden rule to respect during a diagnosis?