Troubleshooting Methodology 2: Scoping the Problem

Part 1 is available here

The following Einstein quote is probably apocryphal, but that doesn’t make it any less useful:

“If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.”

Scoping the problem or determining the proper question to ask is honestly the most important part of the whole troubleshooting process, as if you don’t know what the problem is how can you fix it? Also, if you don’t define the problem how do you know it’s a problem? That one is a little odd but true but the “issue” could just be a configuration that is never going to work.

A long time ago I used to be broadband support tech in a ISP. Wireless routers were new on the market and just being rolled out. Soon after I started supporting broadband  (previously I was supporting only dial-up) I had a call with a customer who couldn’t get their internet working. After about 5 minutes struggling to get a handle on the problem and checking some things on the computer, I went back to the beginning and asked them where their router was. The response was, “Oh that thing? That’s in the shed. Why would I need it – the internet is wireless.”

This one has always stuck in my head. If I had have nailed down what the issue was in the beginning, it would have been a faster solution and there would have been far less messing around. It also illustrates that sometimes the issue may not be a technical problem but a configuration problem. The setup the customer had was obviously never going to work. Correct scoping helps fix these too, and helps keep you clear of rabbit holes.

For scoping a problem I generally have a list of questions that I run through. Some, or even all of them, may not apply to every case, but it’s a good starting point.

The List:

  • What is happening? By this I don’t mean the overall issue, I mean the symptoms of the issue. Computer blue screening would be an obvious example of a symptom rather than an issue.
  • Has this setup ever worked? Is it a new configuration or something that has been in place for some time?
  • What is the configuration trying to accomplish?
  • If it has, when was the last time it worked?
  • How many issues are they experiencing? If more than one, are they all different or related?
  • How many users is this affecting? How many servers is this affecting?
  • How severe is the problem? Crashes , slowness, application crashes or just a vague feeling of unease.
  • If intermittent, how frequent or random is it?
  • Is it reproducible?

Troubleshooting Methodology 1 : Intro


Like a lot of people working in IT, I ended up doing this job because of the enjoyment I get out of fixing things and generally tinkering with various bits of technology. Curiosity about how things work would probably be the biggest driver in my career (and life – but that is another topic!) Thinking back on it, I would have to say that my earliest memory of troubleshooting would be “helping” fix the upstairs phone with my father (who is a telecoms engineer) when I was about 5. This was a great introduction to troubleshooting as it was such a hands-on problem, but more on this later.

Over the years I’ve spent working in technical support, I’ve noticed people tend to troubleshoot things in one of two ways:

  1. Working on intuition and essentially just randomly making changes with no real reason for making the changes (The Potluck Approach)
  2. Gathering some information, drawing some conclusions and then making changes (The Structured Approach)

The second method is rarer than you would think. Sometimes randomly pushing buttons will fix a problem faster, simply through luck, but overall taking a structured approach is faster and results in fewer disasters caused by pushing the wrong button. It also means you generally learn what caused the problem and thus can prevent it from happening again.

My approach to problems is straightforward enough but I’ve found it does help. Below is my general, step by step, approach:

  1. Scoping the problem:  What is happening and (sometimes) why is this a problem?
  2. Data collection: Varies from problem to problem but usually includes environmental information, version of software, when it last worked etc.
  3. Analysis: Looking at the data collected and seeing if there are any indications of a problem.
  4. Result and conclusions: This varies based on where the analysis has led you. Sometimes you’ll have to go back, change what you’re looking for, and take a different tack.

The result of the historic phone troubleshooting? We ran the cables and initially it didn’t work. Then we checked the first junction box and got a signal, so the problem was between the junction box and the terminating socket. Turned out it was the socket. This might be a basic example, but the benefit of a structured approach is that it applies to all problems. If we apply the structure to the steps taken, it would look like this:

  1. Scoped the problem: Phone wasn’t working.
  2. Data collection: Checked how far the signal was getting.
  3. Analysis: Problem was between junction box and socket.
  4. Results: As replacing the socket was easier than ripping the cable out of the wall, we tried replacing that and hey presto it worked without tearing the wall apart. Success!

To NUC or not to NUC

Intel Next Unit of Computing or NUC, you’ve probably heard of them. Essentially they are a very small form factor computer that Intel produce and sell as a reference design to show that regular PCs can be small and relatively affordable. NUCs come with a range of processors (atom, Celeron, i3, i5) and a range of specs (here, here and here being some examples). All they need is ram and a Hard drive to get them going.

Recently my wife was in need of her own computer so decided to go with the Intel NUC as it would be small and tidy. The monitor had a VESA mount which allowed the NUC to be mounted on the back and with a wireless keyboard and mouse the end result was extremely tidy. Making everyone happy.

The spec of the NUC was as follows

NUC: Intel DN2820FYKH Barebone Desktop (Celeron N2820 2.39GHz, HD Graphics, WLAN, Bluetooth 4.0)

Hard Drive: Intel 530 Series 120GB SSD

Ram: Kingston ValueRam 8 GB DDR3L 1600 MHz SODIMM CL11 Memory Module

Monitor: BenQ GL2250HM 21.5-inch Widescreen LED Multimedia Monitor

Couple of gotchas about the Intel NUCs generally and this model specifically

  1.  The ram must be the low voltage ( 1.35v) Sodimm modules. Normal voltage ram will not work in an Intel NUC. There is a supported memory list which lists out the full specs of the ram :
  2. For this specific model of NUC you have to use a 2.5 inch hard drive as opposed to a m-SATA hard drive. However to fit the drive bay of the NUC the RAM must be no thicker than 9.5mm.

The installation of a Windows 8.1

Honestly this was the most painful part of this process, the windows installer loaded fine all the pain came from the NUC.


  1. SSD not detected
  2. BIOS screen not displaying on monitor

To install and operating system on the intel NUC DN2820FYKH you need to upgrade the BIOS from the factory shipped version of 0015 to a minimum of 0025 along with making some fairly minor changes to the BIOS settings. As you can probably imagine the inability to see the BIOS screen made flashing the BIOS less straightforward but not impossible. Intel supply the BIOS updates in 4 packages :

  • Recovery BIOS update : used for flashing directly from the BIOS screen
  • iFlash BIOS update : DOS based utility for updating the BIOS
  • Self-extracting windows based update file
  • Self-extracting windows PE update file

In my case the simplest fix was to make a windowsPE boot USB instructions here , then copy the appropriate BIOS version to the drive. Then boot into the windows PE and run the .exe which then updated the BIOS and all proceeded smoothly from there. The SSD was detected and OS installed.