First of two parts
[img]2298|right|David Voncannon||no_popup[/img]How you recover from a failure depends on how you have planned and prepared for that inevitable failure.
My fulltime day job is working as a technologist. That means I work with companies and individuals to solve problems related to the technology products they use to get their job done or to entertain themselves.
In practice this means fixing malfunctioning computer systems, televisions, networks or explaining the workings of these complex devices to their confused owners. In this role I often hear comments along the lines of “I bet you never have anything like this happen to you.”
Unfortunately that is not the case. As technology geeks, we have access to, and buy, the same products you do. The implication is that we suffer through the same failures and problems you do.
I want to tell you about the latest failure on one of my systems. The failure was on the very laptop computer I am using to write this essay. In a way, that gives away the punch line, knowing that the computer survived to compute another day. But the path from failure to working computer is interesting. I believe it teaches important lessons for users of computer systems.
What happened? I was in my workshop, also known as the family room of my house, working on a customer system with a virus infection. My laptop, a Dell E6510, was on my chair, powered on and displaying my email inbox but otherwise not busy. Without warning, the screen changed from the email inbox to the famous Windows BSOD, also known as the “Blue Screen of Death.” That means that the system had encountered an error so serious that it could not continue operation.
Several minutes passed before I noticed the error. After all I was deeply engrossed in the problems with my customer’s machine. When I did notice, I was shocked. System failures serious enough to cause a BSOD are rare. The messages displayed on screen after a BSOD include diagnostic information. In this case the diagnostics did not provide enough information to specifically identify the problem.
Lacking a better course of action, I restarted the system. It restarted normally and allowed me to look at other system information in the event logs. Windows keeps records of almost everything that happens on the system. Again, there was no smoking gun or clues to help with the diagnosis. Since the system seemed to be normal, I left it running and returned to the customer system.
(To be continued)
Mr. Voncannon may be contacted at dvoncannon@pacbell.net
