Thursday, April 12, 2007

Seeing Crimson...

Sorry, couldn't resist that little play on words for this inaugural blog post. We're wrapping up development right now on new libraries to support the management of logs on Microsoft Vista. In case you haven't heard, Microsoft has introduced a new logging format in Vista, EVTX files. Back in Vista's beta days, this logging format was code-named Crimson.

So far, the development experience has been quite an eye opener. While the ReportEvent function, which is the cornerstone function for writing to the event log in the legacy EventLog API, works great in Vista, other Legacy API techniques do not. For instance, if you try calling the OpenBackupEventLog function on Vista to open a saved legacy EVT file, the function will fail. Interestingly enough, Microsoft has still not updated its documentation at MSDN to reflect this problem as of this writing: http://msdn2.microsoft.com/en-us/library/aa363671.aspx

Going in the other direction, legacy Windows clients (e.g. NT/XP/2000/2003) can open a handle to a "live" Crimson/EVTX log on Vista remotely, but the traditional techniques used to parse through and render the data on such a log will most likely fail due to a variety of other reasons that relate to the hardening of Vista's networking and new message provider data stores. On top of that, legacy Windows clients simply have no mechanism for reading saved Vista EVTX log files whatsoever.

While the Crimson/EVTX format does confer advantages over its predecessor, such as XPath queries, we're still not sure why Microsoft elected to cripple the OpenBackupEventLog function on Vista while supporting other legacy EventLog API calls. Certainly, from a programmatic standpoint, it would appear that the function does little more then read linked data structures out of a saved binary file. One perhaps controversial theory is that Microsoft wanted to make transitioning to Vista much easier for publishers of Windows events (e.g. software developers whose programs write to the log), than for the consumers of the those events (e.g. the utility software vendors whose programs manage and analyze log files). Considering Microsoft's efforts to increase market share in the server management market, that could be the case.

Regardless, we've found cool new ways to work around these potential trouble spots and look forward to introducing Vista/Longhorn compatible versions of our software very shortly.

No comments: