Skip to content

Add Exception field to ETW logging event#125727

Draft
rosebyte wants to merge 1 commit intodotnet:mainfrom
rosebyte:hotfix/etw-exception
Draft

Add Exception field to ETW logging event#125727
rosebyte wants to merge 1 commit intodotnet:mainfrom
rosebyte:hotfix/etw-exception

Conversation

@rosebyte
Copy link
Member

@rosebyte rosebyte commented Mar 18, 2026

Fixes #43092

add Exception field to ETW event

Copilot AI review requested due to automatic review settings March 18, 2026 13:25
@rosebyte rosebyte marked this pull request as draft March 18, 2026 13:27
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds exception text to the FormattedMessage ETW event emitted by Microsoft.Extensions.Logging.EventSource, so consumers of the formatted-message keyword can also see exception details.

Changes:

  • Extend LoggingEventSource.FormattedMessage (EventId 1) payload to include an Exception string field and bump event version.
  • Update EventSourceLogger to pass exception?.ToString() (or empty string) into the formatted-message event.
  • Adjust existing tests to validate the new Exception field presence for formatted-message events.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
src/libraries/Microsoft.Extensions.Logging.EventSource/src/LoggingEventSource.cs Adds Exception to the FormattedMessage event payload and bumps event version.
src/libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLogger.cs Populates the new Exception payload field when emitting formatted-message events.
src/libraries/Microsoft.Extensions.Logging.EventSource/tests/EventSourceLoggerTest.cs Updates expectations to include the new Exception field in formatted-message event JSON.
Comments suppressed due to low confidence (1)

src/libraries/Microsoft.Extensions.Logging.EventSource/src/LoggingEventSource.cs:163

  • FormattedMessage treats EventName/FormattedMessage as nullable and normalizes them to string.Empty, but the new Exception parameter is non-nullable and only guarded by Debug.Assert. For consistency and to avoid a potential NullReferenceException in release builds if any future caller passes null, consider making Exception nullable and normalizing it like the other optional strings.
            string? EventName,
            string? FormattedMessage,
            string ActivityTraceId,
            string ActivitySpanId,
            string ActivityTraceFlags,
            string Exception)
        {
            Debug.Assert(LoggerName != null);
            Debug.Assert(ActivityTraceId != null);
            Debug.Assert(ActivitySpanId != null);
            Debug.Assert(ActivityTraceFlags != null);
            Debug.Assert(Exception != null);

            EventName ??= string.Empty;
            FormattedMessage ??= string.Empty;


You can also share your feedback on Copilot code review. Take the survey.

Comment on lines 137 to 138
/// FormattedMessage() is called when ILogger.Log() is called. and the FormattedMessage keyword is active
/// This only gives you the human readable formatted message.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Microsoft.Extensions.logging events don't contain the real exception message under FormattedMessage event

2 participants