Announcing dotnet-wtrace 1.0

I am happy to announce that the first version of dotnet-wtrace is available for download ๐ŸŽ‰๏ธ Like wtrace, it is an open-source, command-line tool that collects process traces in real-time and displays them in the standard output. However, dotnet-wtrace focuses only on events coming from .NET applications. It uses EventPipe to read runtime and application events and works with .NET Core applications (2.1+) on all the supported platforms.

The reasoning for creating dotnet-wtrace was that I could not find any tool that will show me .NET trace events in real-time. Until now, we could only record the trace (using dotnet-trace or PerfView) and later analyze it. Of course, this approach works in all situations, but sometimes it could be a bit tedious, especially for easy-to-diagnose bugs, such as swallowed exceptions or networking problems. Dotnet-wtrace should help in such cases, quickly pointing you to the error details. It is not meant to replace dotnet-trace or PerfView, but rather help in the initial phases of diagnosing problems. That’s why it does not simply dump all event details but preprocess them and extracts only the most interesting bits, making the output human-readable. Dotnet-wtrace includes multiple event handlers, each one of them handling a specific event category (such as GC, network, loader, or ASP.NET Core events). An example output looks as follows:

As in wtrace, you may choose the handlers and specify event filters through the command-line options. Please have a look at the documentation to learn more.

I hope I convinced you to give dotnet-wtrace a try. You may install it as one of the dotnet tools:

dotnet tool install -g dotnet-wtrace

Or download the precompiled binaries from its repository release page.

Happy tracing and until the next time! ๐Ÿง๏ธ

Announcing wtrace 3.0

After weeks of work, I am happy to announce the new release of wtrace. The 3.0 version is a complete rewrite, with many fixes and new features.

One of the most significant changes is the possibility to collect traces system-wide. If you donโ€™t provide a file path or PID, wtrace will trace all the processes. To keep the number of trace events acceptable, consider using one of the extensive filtering options (a new feature, too!).

You may also choose the event handlers for each session. The sensible default set includes process, file, RPC, and TCP handlers. The 3.0 version introduces a Registry event handler, so if you enable it, you may trace Registry operations with wtrace! I plan to add handlers for less common event types in future releases, too.

The summary section got a new view that displays a process tree. When tracing system-wide or system-only, the tree includes all the running processes. In other modes, you will see the parent process and all its descendants.

The missing file paths are no longer a prevalent issue. And wtrace can finally run in a Windows container (thanks to updates in the TraceEvent library).

Unfortunately, I needed to drop support for ALPC and PowerShell events. In the previous versions of wtrace, I tried to match ALPC connections with the RPC ones, but it never worked reliably. Similarly, the PowerShell event handler had much to improve. I want to revive those handlers, but I need to be sure that they present accurate data. And that requires some more research.

Finally, wtrace has its homepage now:, and I hope that soon new utilities will join its Tools section.

Get the new version from the release page and start (w)tracing! ๐Ÿ˜ƒ