Skip to content

Latest commit

 

History

History
90 lines (51 loc) · 4.49 KB

clr-etw-tracing.md

File metadata and controls

90 lines (51 loc) · 4.49 KB

CLR ETW Tracing

based on:

CLR tracing providers

There are two main CLR providers: the runtime provider ({e13c0d23-ccbc-4e12-931b-d9cc2eee27e4}) and the rundown provider ({A669021C-C450-4609-A035-5AF59AF4DF18}).

Installing CLR tracing

If .NET Common Language Runtime provider is not installed you might need to enable it manually:

mofcomp CLR.mof

Controlling CLR tracing

The CLR provider must be installed on your machine. If you don't have it than go to the framework directory and run:

wevtutil im CLR-ETW.man

The main ETW .NET provider:

.NET Common Language Runtime {E13C0D23-CCBC-4E12-931B-D9CC2EEE27E4}

To start collecting events with logman use:

logman start clrevents -p {e13c0d23-ccbc-4e12-931b-d9cc2eee27e4} 0x1CCBD 0x5 -ets -ct perf

keywords: 0x1CCBD = 11100110010111101 (they are defined in the manifest file)
level: 0x5 = win:Verbose (winmeta.xml)

Additionally you may define cyclic buffer with specific size (eg. 64KB) using the following parameters:

-bs 64 -ct perf

Stop with:

logman stop clrevents

To view events we need to convert the output file to some readable format:

tracerpt clrevents.etl

Start collecting using xperf:

xperf -start clr -on e13c0d23-ccbc-4e12-931b-d9cc2eee27e4:0x1CCBD:5 -f clrevents.etl

And stop with;

xperf -stop clr

Profiling managed code with ETW tools

The great tool for profiling is perfview - describe in seperate document. Starting from Windows 8 it is also possible to get meaningful stack traces from WPR and XPerf.

Problems on x64 (Windows 7 and before)

From http://social.msdn.microsoft.com/Forums/en-US/b7098a78-6600-456a-813e-79a84b994f32/wpr-and-managed-call-stacks?forum=wptk_v4

It is a known issue that for X64 Processes before windows 8 (server 2012), the ETW stack crawling logic stops at the first frame whose code was dynamically generated (that is Just in time compiled). This issue is fixed in Windows 8.

You can work around the problem by

  • Running the app as a 32 bit application
  • NGENing the code you care about.
  • Run on Windows 8

There is a whole section on this in the PerfView users guide that goes into these mitigations. See the FAQ or 'BROKEN stacks'. These mitigations will work for WPR too.

Prepare symbol files for profiling

Based on WintellectPowerShell: Create NGEN PDBs for Easier Profiling on Win8/Server 2012 and Creating NGEN PDBs for Profiling Reports

.NET Framework assemblies are ngen-ed while installing. In order to resolve symbols implemented in them you need to have access to the symbol files to the ngen-ed versions. Fortunately we can easily generate them. For this purpose we can use ngen createpdb <dll-path> <symbols-dir> or Add-NgenSymbols available in WintellectPowershell module. WPR does this job automatically by creating a NGEN symbols folder next to the .etl file. In order to be able to profile applications' source code you need to generate pdbs with lines support: ngen createpdb <dll-path> <symbols-dir> /lines <directory-containing-original-pdb>

Links