|< Day Day Up >|| |
Despite your best intentions, you may some day ship an application to customers without including any logging capabilities. While I’d recommend against doing this, there are other ways to collect the information that you’ll need if a problem occurs. In addition to depending on what your customer can tell you about the error, you can run diagnostic software to help you find the reasons for any failure.
Fortunately, Microsoft provides several diagnostic tools that you can use for your own purposes. The first of these is the System Information utility, shown in Figure 10.3.
Figure 10.3: The System Information utility
The System Information utility is available on all of the recent Microsoft operating systems, and collects all manner of system information into a single interface. For example, if you want to know the screen resolution and color depth that your users are running with, as well as their video driver details, they can find all of that collected in the System Information tree under Components/Display. To launch the utility, select Start Programs Accessories System Tools System Information. Alternatively, select Start Run and launch MSINFO32.EXE. Particularly if you want to collect a variety of information, users will find this utility easier to use than opening a dozen other windows.
If you need a truly comprehensive collection of diagnostic information, try the Microsoft Product Support Reporting Tools (www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en). These are a set of scripts from Microsoft designed to collect information without making changes to the system where they’re run (beyond leaving some files on the hard drive). A variety of separate scripts are available; for general-purpose use, try the Base/Setup/Storage/Print/Performance script. On my Windows XP test system, this script collected several megabytes of information and compressed it into a single cabinet file. The information ranges from event log dumps to the group policy entries for the current user to Registry entries enumerating hot fixes to selected Registry keys. One caution, though: It can take 15 minutes for this script to complete its work, so be sure that your users have a block of time open and have saved their work before running it.
TECHNOLOGY TRAP: Think First!
Now that you’ve got logging on your mind, it’s time to take a step back. It’s all too easy to rush into a morass of detail when a bug pops up in your code. Whether this involves dropping into the debugger and setting watches and interrogating the values of variables when you’re developing the software, or poring over log files and diagnostic information after the software has shipped, the detail is not the place that you should start.
Before diving into the details, take at least a few moments to think about what happened. Perhaps you can deduce the cause of the error simply by realizing what you’ve done wrong, or at least narrow down the portion of the code where it’s likely to be. Does the error message tell you exactly what happened? Did the user try something that you never considered during testing? These can be much more important clues than a ream of step-by-step logging.
It’s good to have logging available as a way to collect information when a truly mysterious bug occurs. But don’t forget to look at the forest before you focus on the individual trees.
|< Day Day Up >|| |