Like This Blog 1

Added by Mike Danseglio November 9, 2012

In a previous article: The Microsoft Troubleshooting Methodology – Simple and Flexible, I explained how I follow a simple and straightforward troubleshooting methodology. That article shows the way this methodology works and how it functions as a troubleshooting framework for almost any computer problem. Here’s a reminder of my approach.

Figure 1. MikeDan’s Quick and Dirty Troubleshooting Methodology.

Identifying the symptom is the critical first step, and is the focus of this article.

What’s The Apparent Symptom?

The common initiators for the entire troubleshooting process are either undesired behavior or an error message.

The error message is certainly easier to focus on. It is tangible, usually specific, and I can persuade anyone to read it to me verbatim or grab a screenshot. Take a look at Figure 2 for a rather clear error message.

Figure 2. A Windows IP address conflict error.

But don’t think for a moment that an error message is always informative or even leads to a better understanding of the problem. Consider Figure 3 as an antithesis of all useful error messages.

Figure 3. I hope you never see this error message.

Error messages are often the first step. Complaints and problem descriptions are also pretty common. Neither usually identify the root cause immediately. You must consider what other symptoms might be occurring to be able to focus on identifying the cause.

Find the Edge and Go Beyond

When you find an error or identify a symptom, are there other symptoms? For example when I encounter the error shown in Figure 2, I would ask myself or the user these questions immediately.

• Are other computers also receiving a similar error?
• Is the affected computer still communicating on the network? If so, all communications are working or some?
• Has there been a recent change to the computer or network, and is there any possible correlation between the symptom and that change?

And finally…

• Is the error message telling me the truth?

It’s that last question that I really love. Some error messages or symptoms have many possible causes. And the knee-jerk response to a symptom in those cases just wastes time and fixes nothing.

To illustrate the point, the error message in Figure 2 has nothing to do with an IP address conflict. It was actually the result of duplicate media access control (MAC) addresses. Because Windows doesn’t have a Duplicate MAC Address message, it displayed the closest thing. While Windows certainly had good intentions, stopping at that symptom would have Windows leading me in the wrong direction. Going beyond the error or first symptom is critical to gathering enough data to find the root cause of a problem.

Conclusion

To really nail down the symptom I start with the apparent stuff: exact error messages, specific symptoms, etc. As quickly as possible I try to gather more data to determine if other symptoms exist and whether the symptom is a false lead. I do all of this before I fix on any single cause. Gathering enough data and asking a few key questions up front are often the difference between chasing false causes and determining the true problem.

Stay tuned for future articles on root cause analysis and creating, testing, implementing, and verifying a resolution.

Mike Danseglio -CISSP
Interface Technical Training – Technical Director and Instructor