Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


General techniques:  Problem solving and troubleshooting

Posted on 2004-08-06
Medium Priority
Last Modified: 2010-05-18
I have been asked to give a 30 minute presentation on problem solving and troubleshooting for an upcoming IT Staff meeting.

The Experts in this TA are skilled in analysis.  I am counting on you to review my presentation so far and give constructive criticism and new ideas.  Even though my audience will be technically savvy...the problem-solving ideas do not have to be IT-centric at all.


Here is what I have so far:


There is some mental preparation before tackling any problem.

-Mindset is important.  Look at problems as intellectual puzzles to be solved.  Avoid internalizing the problem or seeing the problem as a problem with YOU, especially if you've made a significant contribution to the project along the way.  As Spock would say, avoid letting emotion cloud your judgement.  Nobody thinks well when they are upset.


-A lot of important information can be gathered when you are FIRST told about a problem.  Capitalize on gathering this information as close to the problem event as possible.  The more time that passes, the more difficult it may become to find out how the problem happened, when it happened, and how to reproduce the problem.

-Try to define steps that can be followed to reproduce the problem.  


There are four engineers travelling in a car; a mechanical engineer, a chemical engineer, an electrical engineer and a Microsoft Windows computer engineer. The car breaks down.

"Sounds to me as if the pistons have seized. have to strip down the engine before we can get the car working again", says the mechanical engineer.

"Well", says the chemical engineer, "it sounded to me as if the fuel might be contaminated. I think we should clear out the fuel system."

"I thought it might be a grounding problem", says the electrical engineer, "or maybe a faulty plug lead."

They all turn to the Computer Engineer who has said nothing and say, "Well, what do you think?"

"Let's close all the windows, get out of the car and then get back in again?" says the computer engineer.

-Pay attention to intuition.  The first guess is often the correct one.
-Document your findings as you go to keep from re-visiting the same places unnecessarily.
-Ask for help in areas where you have less expertise.  
-Refer to your findings when you do this, so interested parties have the info they need to help you or offer more insights.

Steps While Troubleshooting:

1)  Scan - done very quickly (5 minutes for this activity).  Catches 80% of the bugs
      -Purpose is to eliminate easy to fix human errors
            -Simple logic errors

STEP 1 is “Done” when you start to get stuck or the problem is not immediately recognizable.

2)  Perform “Deep Search” / Extended Troubleshooting
      -Purpose is to find the logic errors that are not recognizable during a quick scan of the code.  Consider that “bad” design may be the problem.
      -Force yourself to SLOW DOWN.  If someone is available to help you, try explaining the problem step-by-step.  Sometimes the act of forcing yourself to explain the problem will yield the answer.  For some people, having a self-dialog as you go can accomplish the same thing...and sometimes an interactive approach is more useful.
      -Avoid “glossing over” areas that you think are working.  The temptation to gloss over an area should raise a flag (do you really understand what is happening in a particular function or subroutine?)
      -Establish internal dialog with yourself….explain why each line of code exists, and why it is necessary.  Doing this is the reason most bugs are found when someone else is sitting next to you and asking you to explain what is happening in the code.  The process of explaining the bug to someone else forces you to explain areas of the code you have been glossing over when no one is around requiring you explain it.
      -Set breakpoint and go through code line-by-line, looking for an explanation as to why the problem is occurring.
      -Create “output” messages to show values, etc.  Some available tools are:
            -Immediate Window
            -Logs (temp table or a physical file)
            -Watches (variable values while stepping through code)

Questions to Ask Yourself While Troubleshooting:

1)  What is the Input  (list each value coming into the system)
2)  What is the expected Output?  Did it happen?  Why not?
3)  Hard to solve bugs are where you get a different output than the input should have given you.


Transformation Process (Validation, or some function or subroutine)


4)  Divide and Conquer.  Break into smaller pieces.  Create a small application that does ONLY the one thing you are having trouble with.
5)  With SQL Statements:  Remove WHERE condition and see if you still get errors.
6)  Reduce complexity where possible.
7)  Pay attention to RECENT changes to that portion of the code or related code that may have broken the system.

Other Notes:
Distinguish between solving symptoms and the root problem.  Fixing the symptoms does not mean fixing the problem that causes it.



User Manual.  RTFM.
Dedicated Newsgroups
Question by:Tom Knowlton
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
1 Comment
LVL 37

Accepted Solution

gregoryyoung earned 2000 total points
ID: 11740736
An example I always give is to make people give specific directions on how they get to work in the morning ... then they begin to realize the types of rules that are required in code (which is very important). I then in their process of telling me start asking questions of "What if the street is closed ?"

I tend to ALWAYS put in logging that is optional ... not necesarily a bad technique for "     -Create “output” messages to show values, etc.  Some available tools are:
          -Immediate Window
          -Logs (temp table or a physical file)
          -Watches (variable values while stepping through code)

Another thing I tend to hit on is isolation and reproduction in a controlled environment because they are the most important parts of debugging an issue.

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction Although it is an old technology, serial ports are still being used by many hardware manufacturers. If you develop applications in C#, Microsoft .NET framework has SerialPort class to communicate with the serial ports.  I needed to…
Calculating holidays and working days is a function that is often needed yet it is not one found within the Framework. This article presents one approach to building a working-day calculator for use in .NET.
Want to learn how to record your desktop screen without having to use an outside camera. Click on this video and learn how to use the cool google extension called "Screencastify"! Step 1: Open a new google tab Step 2: Go to the left hand upper corn…
Please read the paragraph below before following the instructions in the video — there are important caveats in the paragraph that I did not mention in the video. If your PaperPort 12 or PaperPort 14 is failing to start, or crashing, or hanging, …

609 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question