NTrace 1.0 (Beta) Released - Event Tracing for Windows (ETW) for C# Developers

Andy Hopper's Blog - Announcing NTrace v1.0

“I’m pleased to announce the general availability of the NTrace library and preprocessor. NTrace is a combination of a runtime library and a preprocessor that enables you to incorporate the same kind of tracing flexibility and performance that was previously only available to the lucky folks still writing unmanaged code. There are a log of advantages to using NTrace/ETW: higher performance, flexibility, and zero-config tracing.

In terms of performance, we’re talking orders of magnitude faster when no tracing is being performed, and 2-3 faster when tracing is enabled. …

In terms of flexibility, you can configure ETW tracing to log in many different ways: real-time to a console (similar to listening to the OutputDebugString spew), logging to a flat binary file, logging to a binary circular log, and for those with intestinal fortitude, writing a custom ETW listener (we do plan to eventually surface this via the NTrace API as well).

However, I’ve saved the best for last: one of the best features of the ETW tracing APIs is the ability to turn tracing on in your applications without needing to modify any configuration files or restart it …

…”

CodePlex – NTrace

“NTrace is a library that provides flexible, high-performance, and zero-config trace logging for your C# applications.

NTrace is currently 100% C#.

…”

NTrace - Using the ETW tracing preprocessor in your Application(PDF)

“What is this ETW thing?
Event Tracing for Windows is a kernel-level tracing service that has been around since Windows 2000. Since it’s baked right into the kernel, it is extremely fast. Most of the developers that use ETW are writing drivers, but why should they have all the fun?

Why should I use ETW?
ETW Tracing has several benefits over the tracing classes provided with the .NET Framework. Most importantly, ETW tracing can be turned on and off without having to restart the application, but it also has features like built-in high performance circular logging (a circular log is one that never grows above a specified size by flushing out older trace messages), and the ability for you to capture the logs from multiple sources into a single trace session.

What is this preprocessor and why do we need it?
Put simply, to maximize application performance when tracing is not enabled. In a perfect world, an application’s performance when tracing is disabled would be identical to one where tracing wasn’t included at all. The problem is that your code is only compiled once; if those trace calls are in there, they’re GOING to get called, and while the ETW functions return quickly when tracing is disabled, the runtime still has to evaluate trace arguments, allocate memory, construct method call stacks, and so on. The application performance would be even faster if the functions were never called in the first place.

…”

Sounds pretty cool. I’m a little bummed that this seems for C# development only (due to the changes in the build process). I’ll be keeping my eye on this anyway, as well as for a way where I can use this (since most of my projects are VB  ;)