There's one other type of log that we should discuss: Windows event logs. Although these logs are intended more for administration than for debugging, they do sometimes help solve bugs. Your application should output its own debugging log, which isn't meant to be read by the end user. But there are also some types of log messages that end users do care about, and those messages need to be logged to a central place where users can read them. For instance, if Microsoft Exchange successfully starts up, it will say so in the event logs. But if it fails to start up, then the event logs note that instead. The end result is that the user gets a view of what the program is doing without having to figure out the format of proprietary debugging logs.
Prior to.NET, writing to the event logs was a surprisingly twisted process, but it's easy now—just set an EventLogTraceListener on the Trace and Debug classes, and you can write to the event logs just as easily as to your own debugging logs. By setting that listener in your XML config file, you could switch all your debugging logging to go to the event logs without even recompiling your code! But you probably shouldn't, because the information appropriate for a debugging log is very different from that appropriate for the event logs. Writing useful messages to the event logs is important for other reasons—but since such messages are usually not used for debugging, that will remain the subject of a different book. You shouldn't clutter the event logs with pure debugging messages.
However, even though you probably won't have to write debugging messages to the event logs, you'll often find it helpful to see the messages that other people wrote there. Especially if your software interacts heavily with another program, the event logs show what difficulties that program encountered. Say your application uses a SQL Server database, but your code fails to retrieve data for some reason. The event logs are your best chance of finding out what the database is doing. They will tell you if SQL Server is currently experiencing an error. If so, then you know your code will never work until the database is fixed, and you can focus on doing that instead of searching for a bug in your own code.
Windows itself writes to the event logs heavily, and for debugging certain types of errors, those event messages are worth their weight in gold. If your program is a Windows service, the event logs are especially useful because they're the easiest way to see why your service failed to start (see Figure 5-2). That's a common and annoying problem because it usually has nothing to do with your code; rather the user did something silly like change the password of the account that runs the service. Even though the problem isn't in your code, customers will still call, asking you to fix the problem. Asking for the customer's event logs will give you the clues you need to solve the issue.
The other nice thing about the event logs is that you can see the problems other applications on the computer are having, which may tip you off about the problem your own program has, even if the other apps are unrelated to your own. I received a very strange bug report one time, and my program's debugging log didn't indicate anything helpful. So I looked at the event logs. There was nothing about my program; however, I did notice some other application complaining about a lack of disk space. Aha! The customer confirmed he was indeed low on disk space, and after he deleted some unused files, my program started working again. Lesson learned—I added code in the next version to log my own message about insufficient disk space, but I also realized the value of using another program's reported errors to fix my own!
Bottom line: Your application may need to write messages to the Windows event logs for other reasons, but you shouldn't write any debugging information there. Despite that, though, the event logs are still often useful to have when debugging. When you're stumped on a bug, ask the customer if she will share them with you.