EventSource::SendManifest causes lost events which result in unmergable ETL files #77014
Description
Description
When doing ETW recording on Windows I have found that whenever a .NET 6.0 application is traced it will emit the ETW manifest whenever a .NET runtime session is started. These events are large (30+KB) and will cause from multiple processes (I have many .NET services running on that box) an event storm which will cause ETW to cause event drops.
That in itself is not too bad, but sometimes the ETW files become corrupt so that the merge operation with xperf or PerfView will fail. That is an issue.
Reproduction Steps
- Start many .NET 6 applications
- Start ETW Session for .NET Runtime provider
C:\etl>xperf -start ClrSession -on Microsoft-Windows-DotNETRuntime -f C:\temp\ETW.clrSession.etl -BufferSize 512 -minbuffers 256 -maxbuffers 512 -FileMode Sequential
- Stop ETW session
C:\etl>xperf -stop ClrSession
xperf: warning: Session "ClrSession" lost 241898 events.
The trace you have just captured "C:\temp\ETW.clrSession.etl" may contain personally identifiable information, including but not necessarily limited to paths to files accessed, paths to registry accessed and process names. Exact information depends on the events that were logged. Please be aware of this when sharing out this trace with other people.
To avoid losing events, for in-file tracing try increasing buffer size or the minimum/maximum number of buffers. It is also recommended that a separate secondary storage device is used for in-file tracing, especially when analyzing secondary storage activity. Another way to avoid losing events is to trace in memory (-buffering mode). This guarantees that events will not be lost, but the time range of events captured can be significantly shorter than with in-file tracing.
- Check if dotnet runtime provider has got lost events
Expected behavior
No lost events
Actual behavior
Lost events and sometimes unmergable ETL files
xperf -merge broken.etl broken.user.etl final.etl -mergeonly
xperf: error: final.etl: The parameter is incorrect. (0x57).
I can provide example ETL files which are broken on a private channel.
Regression?
This was not the case with .NET Core 3.1
Known Workarounds
So far none. Does filtereing the event "fix" this when I later do a proper rundown?
tracelog -enableex ClrSession -guid #e13c0d23-ccbc-4e12-931b-d9cc2eee27e4 -EventIdFilter -out 1 65534
Configuration
No response
Other information
No response