Back in college, at the turn of the millennium, my computer was a PowerBook 520c. Despite its age, it ran well enough for me to check e-mail and bang out essays. One day at startup, though, Mac OS simply would not run, thanks to something called error type 41. I had no idea what that meant, and, rather than investigate further, I packed the laptop back into its bag and never turned it on again. Eventually I paid $5 for it to be recycled.
No developer in his or her right mind would approach application troubleshooting in this manner -- not when there are end users, customers, business partners and bosses who depend on those applications and expect them to run smoothly.
Steve Schofield, a veteran of ASP and ASP.NET development, offers a helpful guide to application troubleshooting here in his blog. "I've been hanging out in the newsgroups lately and it kind of surprised me the same thing about trying to find out 'what's wrong.' Sometimes getting started is the hardest part," he writes.
Schofield offers three main hints to developers and administrators alike.
- First, look in any and all log files available -- event logs, SQL logs and any custom logs you created for the application -- and figure out where exactly the problem occurred. Schofield recommends a few utilities from Sysinternals that will review files, registries and other records for "access denied" errors.
- Next, identify and record all the errors that come up. As this post and discussion thread on SecretGeek points out, error messages, exceptions and the stack call for exceptions offer a pretty good snapshot of what went wrong -- and not remembering what they are will only lead to additional frustration and embarrassment. It's akin to telling a doctor that you are in pain but not saying what part of the body hurts and how long it has hurt.
- Finally, hit the search engines. "I wager a good portion of the time you'll find the solution or an article about your issue," Schofield says. Type in the exact text of your error message into a search engine and see what emerges. Look for forums related to your platform or component and see if anyone has confronted the same issue. Try general forums such as the ITKnowledge Exchange and post messages there. Search the vendor Web site as well. And if all else fails, ask a colleague -- he or she may not have an immediate solution, but a second set of eyes may notice something that you have not.
Application troubleshooting can be a veritable nuisance, but it is a necessary one, given the time and money that enterprises and developers devote to their applications. With that at stake, the options I chose -- surrender, pack up the system and pretend that nothing happened -- are really not options at all.