Computer Troubleshooting For Beginners
Computer troubleshooting can be a lengthy and troublesome task. It’s often referred to as “debugging” — to address the etymology of the word, legend has it that “debugging” dates back to the gigantic vacuum tube computers of WWII. A bug on those early machines could literally mean a moth or other insect stuck in a relay or other piece of electronics, shorting things out and impeding operation. It’s not certain if this is where the term originated, though — some of Charles Edison’s 19th century writings include the word “bug” in regards to unexpected problems.
For troubleshooting problems that are confined to software, the debugging skill of the programmer is crucial. The level of difficulty can vary, though, with the programming language used. Various software tools can enable the troubleshooter to monitor the execution of a program, set breakpoints, stop, re-start or do any number of other manipulations during the program’s run. Higher-level programs such as Java include features such as exception handling that flag the sources or spots of erratic behavior and make them easier to track down. A common tool available to the software troubleshooter is the static code analysis tool. These tools look at the source code to detect problems within the code itself. These can be very useful in instances where there is too much code for the troubleshooter to pick through; some claim to be able to track down as many as 300-plus unique problems.
The first step in debugging is often an attempt to reproduce the problem. That by itself can be difficult in the case of an unusual bug. Once the problem can be reproduced, the input program is usually stripped down to get an easier look at what’s at play. After the test case can be simplified, the troubleshooter can use debugging tools to examine specifics of the program’s state and hopefully track down the origin and nature of the problem. A divide-and-conquer approach is common, removing some parts of the original test case and checking to see if the problem still exists.
Debugging can be done remotely, with the debugger going into the machine through a network. The troubleshooter can then use tools to control the program’s execution and retrieve and store information about what’s going on. Debugging can also be done post-mortem, after an unhandled exception has terminated a process. A crashed program can be debugged by going into the core dump of process space. Print debugging can be accomplished by watching trace statements that show the flow of execution of a program.
Troubleshooting the computer hardware itself as well as low-level software, drivers and firmware, instruments such as logic analyzers, oscilloscopes or in-circuit emulators (ICEs) are common. ICEs may do much of the software debugger’s work on low-level software or firmware.
In some cases, bugs are just left in place; developers may not have time, or it may not be cost-effective to fix non-sever bugs. Plus, there’s always the chance of a simple fix bringing a new, unknown bug into the system. In such cases, the problem is either fixed in a new version or patch, or some sort of workaround is devised.
