This story underscores something that I look for when I'm interviewing for certain kinds of support roles. Basically, it's really hard to teach someone proper troubleshooting. It seems that people either "get it", or they do not. You can give them a flowchart, and lots of training, but it's not the same.
Bas troubleshooters have a hard time assessing just where to start, do we look at the immediate problem as reported, or do we track back through dependencies to a non-apparent possible root? Also, in a stressful situation like this it seems that it takes a certain amount of resolve to change 1 thing at a time and have a way to (quickly!) test your results so that you can actually solve the problem, instead of just pushing out the next occurrence a few weeks.
Another common bug: bad troubleshooters don't verify their hypotheses. They get attached to their first idea of what might be going wrong, and start tweaking things to alter the behavior of whatever they think is at fault --- and after each such tweak fails, it's on to the next, without a pause to consider that the problem might be elsewhere. Time wasted like this can range from hours to weeks.
Where this gets really annoying is when you present them with direct evidence that the problem is elsewhere, and you get back an emotionally driven argument for ignoring it...
Yes, when I debug I first verify all the obvious things with quick sanity checks, and then do a binary search down to the more detailed possibilities. Just yesterday I helped my friend find an inscrutable bug. He checked the inputs (he expected "myString" and indeed got "myString") so he delved deep into the system fruitlessly for hours. When I helped, I quickly uncovered that "myString" != "myString": his input had a carriage return prepended to it!
Bas troubleshooters have a hard time assessing just where to start, do we look at the immediate problem as reported, or do we track back through dependencies to a non-apparent possible root? Also, in a stressful situation like this it seems that it takes a certain amount of resolve to change 1 thing at a time and have a way to (quickly!) test your results so that you can actually solve the problem, instead of just pushing out the next occurrence a few weeks.