microsoft / eventtracing-processing

Issues for the Microsoft.Windows.EventTracing.Processing.All NuGet package

Issues-Only Repository

This repository is currently an issues-only repository for the following NuGet package: Microsoft.Windows.EventTracing.Processing.All (and related NuGet packages, such as Microsoft.Windows.EventTracing.Processing).

For more information on these packages, see the announcement blog post.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

eventtracing-processing's Issues

LoadSymbolsForConsoleAsync() sometimes crashes process with code 0xc0000374 (HEAP CORRUPTION)

The following code sequence occasionally (2-10%) crashes with error code 0xc0000374 (HEAP CORRUPTION):

            var symbols = tp.UseSymbols();
            var cpuSampling = tp.UseCpuSamplingData();
            var events = tp.UseGenericEvents();

            tp.Process();

            await symbols.Result.LoadSymbolsForConsoleAsync(
                new SymCachePath(symCachePath),
                new SymbolPath(symbolPath), 
                new string[] { imageName }); // Occasional error 0xc0000374 (HEAP CORRUPTION)

The crash can occur any time within the symbols loading sequence. The crash is random: immediately rerunning the same code usually completes without error.

Support needed for VirtualAlloc/VirtualFree analysis

VirtualFree and VirtualAlloc stacks can be critical in understanding memory consumption. VirtualFree is particularly interesting for programmatic trace analysis because it cannot be analyzed using WPA - if you just have the free but not the alloc then the data is hidden.

I recently got desperate and wrote code to analyze "xperf -a dumper" output (script is at https://github.com/google/UIforETW/blob/main/bin/VirtualFreeStacks.py). The results were incredibly useful (see crbug.com/1179934) and may help understand a significant memory issue in Chrome and/or Windows, but writing text parsing code to analyze ETW traces seems like the wrong solution at this time.

Text parsing code tends to be more fragile and it also requires additional steps and usually has significantly worse performance than the trace processor library. Text parsing also requires significant investigation in order to understand the layout of the output and what xperf options to use.

Support for Using Traceprocessing Library with WASM

I'm currently converting my C# project to WASM so that it could be used with JS.
I'm using UNO.Bootstrap.WASM for this but willing to explore other alternatives like Blazor,

My C# code uses the TRACEPROCESSING library, to read and parse an ETL file.
The .NET code works without WASM well, however with WASM I run into linker errors for not able to find kernel32.dll
I'm probably running into a WASM limitation of not being able to do File IO.
But is there any way around this?

1. Can the Traceprocessing library be made open source to know the mechanism of how it parses an ETL file?
2. Can Microsoft expose a library similar to Traceprocessing, to parse an ETL file through JS?
3. I have already looked at tools like tracerpt wpaexporter which are extremely slow in csv generation and xperf is fast but has only a set of prebuilt filtering options but not a lot of room for custom filtering like traceprocessing.

Processing a trace with a TraceClockType of SystemTime throws an exception

Processing a trace with a TraceClockType of SystemTime throws an exception:
System.ArgumentOutOfRangeException: 'The TraceTimestampValue does not represent a valid value in the range of the trace's clock. Parameter name: traceTimestampValue'
This exception was originally thrown at this call stack:
Microsoft.Windows.EventTracing.Metadata.SystemTimeTraceTimestampContext.GetRelativeTimestamp(Microsoft.Windows.EventTracing.TraceTimestampValue)
Microsoft.Windows.EventTracing.Metadata.SystemTimeTraceTimestampContext.GetDateTimeOffset(Microsoft.Windows.EventTracing.TraceTimestampValue)

FunctionName does not provide function signature -- unable to differentiate function overloads

The field ICpuSample.Stack.Frames[n].Symbol.FunctionName provides only the function name, not the function signature. E.g. FunctionName returns "main" instead of "main(int, char * *)".
This makes it difficult to differentiate between different function overloads. It is possible to use ICpuSample.Stack.Frames[n].Symbol.AddressRange.BaseAddress.Value for that purpose, but the result is not quite human-readable.
The best option to differentiate between function overloads would be to return the function signature when available -- i.e. when private symbols are provided. To maintain backward-compatibility, a new field ICpuSample.Stack.Frames[n].Symbol.FunctionSignature could be created for that purpose.

Could not get assembly path

Hi,

I am using this library in my tool and I also build my tool as a standalone exe. It is based on .net 5.0. However, when I run my code as standalone exe, I got the below error, but if I build it regularly, it works well. Could you help to take a look this issue and provide some suggestions? Thank you.

Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'path1')
at System.IO.Path.Combine(String path1, String path2)
at Microsoft.Windows.EventTracing.ToolkitTraceProcessingEngine.GetProcessBinDirectoryDefaultToolkitPath(Assembly possibleEntryAssembly, String binDirectory)
at Microsoft.Windows.EventTracing.ToolkitTraceProcessingEngine.GetOrCreateDefaultToolkitPath(TextWriter output)
at Microsoft.Windows.EventTracing.ToolkitTraceProcessingEngine.Create(String path, ITraceProcessorSettings settings, ITraceProcessorSettings& effectiveSettings)
at Microsoft.Windows.EventTracing.TraceProcessor.Create(String path, ITraceProcessorSettings settings)
at Microsoft.Windows.EventTracing.TraceProcessor.Create(String path)

Fail to launch WPTx??-x86_en-us.msi from a path containing a space

When Microsoft.Windows.EventTracing librairies are copied to a directory with a path containing at least one space -- e.g. C:\TMP\New Folder -- WPTx[86|64]-x86_en-us.msi fails to launch upon the first run. An msiexec.exe usage dialog box is displayed.

It appears that the library invokes "msiexec.exe /i C:\TMP\New Folder\WPTx[86|64]-x86_en-us.msi". Because of the embedded space between "New" and "Folder", msiexec fails. The command invoked should instead be: "msiexec.exe" "C:\TMP\New Folder\WPTx[86|64]-x86_en-us.msi".

The workaround consists in copying the librairies to a directory with no space in its full path -- e.g. C:\TMP -- and running the application from there. On the first run, WPTx[86|64]-x86_en-us.msi are installed successfully.