I am going to be honest when investigating issues in production, if given the choice between tracing a process or capturing a memory dump, up until recently, my choice would have been the memory dump. However, some of my colleagues have really impressed on me that there are certain scenarios where tracing is less invasive and provides a whole bunch of really relevant data over time.
Event Tracing for Windows (ETW) is an incredibly efficient tracing mechanism that lets you log kernel or application-defined events to a log file. You can monitor events in real time or, more commonly, just load the events from a log file into an application like PerfView, Xperf or Visual Studio.
You could then use the series of recorded events to debug your application or to determine where performance issues are occurring. I have traditionally approached production diagnostics and debugging using memory dumps but there are many scenarios where tracing your application would be advantageous.
For example ETW lets you enable or disable event tracing dynamically, you can perform detailed tracing in a production environment without requiring application restarts, or even pausing the process. The Event Tracing API, that makes all this possible, it is divided into three components: Controllers (enables providers), Providers (which produces events), and Consumers which consume the events.
CLR Providers
The Common Language Runtime (CLR) has two providers which contain event tracing instrumentation: the runtime provider (which is the main CLR ETW provider) and the rundown provider.
So why we need the Rundown Provider? In all honestly most people do not need to worry about the rundown provider as most everything we need is in the runtime provider. However, in many collection scenarios you attach sometime after the process startup which mean events containing information about symbol resolution are missed. If the rundown provider is in fact enabled for tracing after the process has started it allows for symbol resolution of the managed processes with minimal impact to the running process.
xperf -start clrRundown -on A669021C-C450-4609-A035-5AF59AF4DF18:0xB8:0x5 -f clr2.etl
Comments are closed.