For a while now I’ve been trying to use Windows Events as my logging framework, but I have suffered from one seemingly fatal problem: if my application terminated unexpectedly (thus ungracefully), my session was left open, and I was seemingly unable to stop it or re -enable providers against it. This was beginning to make me feel like Windows Events was not the right framework for debug logging, because an ungraceful termination is very likely during development. However, I have since found that I was not passing the name I thought I was to the StartTrace function, and so although I could close my session as long as my application didn’t terminate (due to some state in my logging class), a “Cold-Stop” (as in a ControlTrace call at the start of my app) would not work.
I have now corrected this bug in my code, and can now close the open session and restart it if I encounter ERROR_ALREADY_EXISTS upon starting my session.
[EDIT 4 September 2010]
Thanks to David M for pointing out an error in my code. When starting an ETW session you should pass in the session name not the log file name. See the correction (in bold) in the LoggingController::Start member function below.
So, Windows Events, its the new Logging API for Windows Vista+, it brings together Event Tracing for Windows (ETW) and Windows Event Log. The basic layout of ETW is that you have an Event Tracing Session, for which you enable providers. These providers write log messages into the session. You can enable the providers with various settings allowing you to filter the type and criticality of the log messages, and do all that fun sophisticated tracing stuff. If you use a “manifest-enabled” provider (more on that later) you get the Windows Event Log side of it for free. You can also create consumers of these sessions, to monitor the logs and stuff. Continue reading “A Quick and Dirty tutorial on Event Tracing For Windows: Part 1 the Event Trace Session”
I started actually writing some code on my new experimental engine today. One of the things I want to do with this engine is write as little code myself as I have to. Also, I’d like to avoid using third party libraries for things Windows already does, like logging. A lot of people would use something like log4cxx, and whilst there’s nothing wrong with that (other than being notoriously difficult to use with MSVC), Windows already has a pretty sophisticated logging API called Windows Events, which unifies both the Windows Event Log, and the Event Tracing for Windows APIs. This is a mature, flexible, high-performance API for logging on Windows, and it is built into the operating system, which to me represents far lower risk than any other options; AND I get built in log-file analysis tools (Windows Event Viewer) to help me peruse my log files.
The catch is that there is a little bit of work involved to wrap around it, as I have found, and the documentation is not awesome. Mind you it is no more work than would be involved in log4cxx to programatically set up your loggers etc.
Today I got to grips with a couple of the Windows SDK samples, and wrote a class which wraps around the Windows Event Trace Session, to allow my engine to set-up and tear-down a session. It still needs a little finessing, but this will come once I have created my own provider (for now I’m using the sample provider app to write events into my tracing session).
I’ll post a short article a little later.