Document EventSourceLoggerProvider non-caching behavior#124075
Merged
cincuranet merged 4 commits intomainfrom Feb 11, 2026
Merged
Document EventSourceLoggerProvider non-caching behavior#124075cincuranet merged 4 commits intomainfrom
cincuranet merged 4 commits intomainfrom
Conversation
…avior Co-authored-by: cincuranet <[email protected]>
Copilot
AI
changed the title
[WIP] Fix possible memory leak in EventSource logger
Document EventSourceLoggerProvider non-caching behavior
Feb 6, 2026
tarekgh
approved these changes
Feb 6, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates documentation in Microsoft.Extensions.Logging.EventSource to clarify that EventSourceLoggerProvider.CreateLogger() does not cache EventSourceLogger instances, and that repeated direct calls can create many loggers (surprising some consumers such as Serilog).
Changes:
- Documented non-caching behavior on
EventSourceLoggerProviderandCreateLogger(). - Added remarks to
EventSourceLoggerdescribing instance creation/tracking behavior. - Added an “Important Notes” section to the package README describing caching expectations.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLoggerProvider.cs | Adds XML remarks about non-caching and why created loggers are retained. |
| src/libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLoggerFactoryExtensions.cs | Adds remarks clarifying caching expectations for the provider/extension. |
| src/libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLogger.cs | Adds remarks about non-caching and linked-list tracking. |
| src/libraries/Microsoft.Extensions.Logging.EventSource/README.md | Adds “Important Notes” section explaining caching behavior and typical DI usage. |
src/libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLoggerProvider.cs
Show resolved
Hide resolved
...libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLoggerFactoryExtensions.cs
Show resolved
Hide resolved
src/libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLogger.cs
Show resolved
Hide resolved
Contributor
|
/ba-g Failures are unrelated to changes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
EventSourceLoggerProvider.CreateLogger()returns a newEventSourceLoggerinstance on each call without caching. This differs fromConsoleLoggerProviderwhich caches by category name. The behavior is intentional (maintains linked list for dynamic EventSource/ETW configuration changes), but was undocumented, leading to confusion when libraries like Serilog callCreateLogger()per log event.Changes
XML Documentation Updates:
EventSourceLoggerProviderclass andCreateLogger()method: Document non-caching behavior and caller responsibilityEventSourceLoggerclass: Explain linked-list tracking for ETW dynamic configurationEventSourceLoggerFactoryExtensions.AddEventSourceLogger(): Clarify caching expectationsREADME.md:
ILoggerFactoryhandles caching (normal DI usage unaffected)ILoggerProvider.CreateLogger()calls require caller-side cachingImpact
Documentation-only change. No behavioral modifications.
Normal usage through
ILoggerFactory(dependency injection) is unaffected as it already implements per-category caching. Only directILoggerProvider.CreateLogger()consumers need awareness.Microsoft Reviewers
Note: Canned responses can be used if appropriate.
Original prompt
This section details on the original issue you should resolve
<issue_title>Possible memory leak in EventSource logger?</issue_title>
<issue_description>### Description
I am seeing a huge number of

EventSourceLoggerinstances when I compare memory dumps over time from my application:It seems that EventSourceLoggerProvider blindly creates new EventSourceLogger instances and adds them to the linked list. This is different from for example the console logger, which have instances in a dictionary keyed by the logger name.
What is the exact contract provided by
CreateLogger(name)? Is it the provider internally that should guarantee that the same logger is returned for a given name (as the Console logger does), or is it the caller?Of cause, if it is up to the caller to cache by name, then this is a bug in Serilog.
Reproduction Steps
Create a simple console app with the following references:
And the following
Program.cs:The app will continue to allocate
EventSourceLoggerinstances indefinitely.Expected behavior
The
EventSourceProvidershould returnEventSourceLoggerinstances keyed by name such that the linked list internally in the provider does not grow indefinitely.Actual behavior
New
EventSourceLoggerinstances are blindly created for every call toCreateLogger(name), which are internally stored in the linked list.Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response</issue_description>
<agent_instructions>Improve docs around EventSourceLogger and explicitly state that instances are not cached and it is expected from client side.</agent_instructions>
Comments on the Issue (you are @copilot in this section)
@ Tagging subscribers to this area: @dotnet/area-extensions-logging See info in [area-owners.md](https://github.com/dotnet/runtime/blob/main/docs/area-owners.md) if you want to be subscribed.Issue Details
Description
I am seeing a huge number of

EventSourceLoggerinstances when I compare memory dumps over time from my application:It seems that EventSourceLoggerProvider blindly creates new EventSourceLogger instances and adds them to the linked list. This is different from for example the console logger, which have instances in a dictionary keyed by the logger name.
What is the exact contract provided by
CreateLogger(name)? Is it the provider internally that should guarantee that the same logger is returned for a given name (as the Console logger does), or is it the caller?Of cause, if it is up to the caller to cache by name, then this is a bug in Serilog.
Reproduction Steps
Create a simple console app with the following references:
And the following ...
✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.