A method for software faults, and why it is the same method as for hardware

Why this matters

Software faults feel different from hardware faults. There is nothing to inspect, nothing to swap, and the machine offers an enormous number of places to poke. That is exactly why a method matters more here, not less: without one, troubleshooting becomes a sequence of plausible changes, and when the fault goes away nobody knows which change did it.

The exam asks about the method directly, and it asks in a specific form: scenarios that describe a technician mid-process, asking what comes next or what was skipped. So this lesson is the method, with the two steps everyone skips called out, and the discipline that makes the middle of it produce usable answers.

The lesson

CompTIA's troubleshooting steps, and the two everyone skips

The method below is the one this course teaches and the one its troubleshooting questions are written against. It is not quoted from a published list — CompTIA's public page for this exam gives four weighted domains and eleven topic areas and nothing beneath them — but its shape is standard across the industry and it is identical to the method the hardware exam teaches, which is the point of the lesson's title.

1. Identify the problem. Gather information, question the user, identify changes, and back up before making changes.
2. Establish a theory of probable cause. Question the obvious first.
3. Test the theory. If it is confirmed, work out the next steps. If it is not, establish a new theory or escalate.
4. Establish a plan of action and identify potential effects.
5. Implement the solution, or escalate.
6. Verify full system functionality and, where applicable, implement preventive measures.
7. Document the findings, actions and outcomes.

The two everyone skips are the first and the last.

Step one is skipped because the technician already has a theory before the user has finished the sentence, and the theory is usually about the last similar case rather than this one. The cost is a fix applied to the wrong fault.

Step seven is skipped because the machine is working and the queue is long. The cost is paid by whoever gets the same fault next — frequently the same person, six months later, with no memory of it.

Everything in between is where the effort visibly goes, and it is the cheapest part to get right.

Reproducing a fault, and what to do when it will not reproduce

A fault you can reproduce is a fault you can test a theory against. A fault you cannot reproduce is a story, and the most common way to "fix" one is to change something and have the fault not recur for unrelated reasons.

Reproducing well means establishing four things:

• The exact steps, in the user's order, on their machine, in their account.
• The exact symptom — the error text, the behaviour, what appears on screen. "It crashes" and "it closes with no message" are different faults.
• The scope — does it happen for another user on the same machine, for the same user on another machine, every time or sometimes?
• The timing — when did it start, and what changed then?

That scope question is the single most useful one in this lesson. Another user, same machine isolates the profile. Same user, another machine isolates the account or the data. Both failing points at something shared — the network, the server, the file.

When it will not reproduce:

• Get the user to record it, or to screenshot the error rather than describe it.
• Look at logs around the times it happened, which is the next section.
• Look for a pattern: time of day, after a restart, on a particular network, after a particular application runs.
• Say so honestly, and put it in the ticket with what you ruled out. An intermittent fault documented across three occurrences becomes solvable at the third; three undocumented occurrences are three first visits.

Changing one thing at a time, and the discipline that makes results mean something

This is the discipline that makes the middle of the method produce information rather than guesses.

Change one thing. Test. Write it down. Then change the next.

The reason is that a result only means something if you know what produced it. A technician who disables two startup items, clears the cache and reinstalls a driver, and finds the fault gone, has learned nothing: they cannot tell the user what was wrong, cannot prevent it, and have possibly left two unnecessary changes in place.

The practical rules:

• Undo a change that did not help, before making the next one. Otherwise after six steps the machine differs from its starting state in six ways, none of them understood.
• Prefer reversible changes first. Toggling a setting before reinstalling; a clean boot before a repair install.
• Prefer tests that eliminate the most. Another user's profile on the same machine takes two minutes and eliminates or confirms an entire category.
• Keep a running note of what you tried and what happened. Three lines, and it is what step seven turns into.

And the exception worth knowing, because it looks like a contradiction: when the goal is restoring service rather than diagnosis — a director with a presentation in ten minutes — do the fastest thing that works, and say clearly in the ticket that the cause was not established. That is a legitimate choice. Making it silently, and letting a restart be recorded as a fix, is not.

Reading logs and error messages as evidence rather than as noise

Logs are the machine's own account of what happened, and most people either ignore them or read them wrongly.

Where they are: Event Viewer's Application and System logs on Windows, with Security for authentication and access; the unified log and Console on macOS; journalctl and /var/log on Linux. Applications keep their own, usually under the user's profile, and an installer log is frequently the only place the real reason for a failed installation appears.

How to read them:

• Filter by time first. Go to the moment the fault happened. A log read from the top is noise.
• Find the first error, not the loudest. A cascade of forty entries usually has one cause at the top and thirty-nine consequences beneath it.
• Errors and warnings are normal. Every healthy Windows machine logs errors continuously. An error is only evidence if it correlates with the symptom in time.
• Read the error text properly. People skim to the code and search for it. The sentence often names the file, the account or the path, which is the answer.
• Correlate across logs. An application error at 10:42 and a disk warning at 10:41 are one event.

The habit worth building: when a user reports a fault, ask what time it happened before you ask anything else. It converts an unbounded search into a two-minute one, and it is the single question that most improves the odds of finding something.

Documenting the fix, and why the next occurrence is someone else's first

The last step, and the one skipped most often, for the worst reason: the machine works and there is another ticket waiting.

What to write:

• The symptom, as observed, including the exact error.
• What you ruled out, which is often more valuable than what you found — it is what stops the next person repeating your first hour.
• The cause, if you established it, and plainly if you did not.
• What you changed, specifically enough to reverse it.
• How you verified the fix, beyond the fault not happening in the thirty seconds you watched.
• Anything the user should watch for.

Why it matters, concretely:

• The next occurrence is someone else's first. They have your machine, your user, and none of your context.
• Patterns only exist in writing. Four machines with the same fault over three months is a defect with a root cause; four separate tickets with no detail is four unrelated annoyances.
• A change you cannot describe is a change nobody can reverse, which is the operational procedures domain's whole argument.
• The next person is frequently you, with no memory of it.

The cost is three or four sentences. The way to make it happen is to write them as you go rather than at the end, because by the end the details have gone — and the details are the entire value.