Skip to content

[release/10.0] Deduplicate "all managed object wrappers" mapping - #133292

Merged
JulieLeeMSFT merged 1 commit into
release/10.0from
backport/pr-133260-to-release/10.0
Sep 9, 2026
Merged

JulieLeeMSFT merged 1 commit into
release/10.0from
backport/pr-133260-to-release/10.0

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 5, 2026 •

Copy link
Copy Markdown
Contributor

Backport of #133260 to release/10.0

/cc @jkoritzinsky

Customer Impact

  • Customer reported
  • Found internally

Ever increasing managed memory usage (memory leak) each time a managed object is passed to COM via ComWrappers, even when reusing the same COM instance. The only workaround is to turn off the "managed debugging" helper APIs.

Regression

  • Yes
  • No

Regressed in #113907

Testing

Local validation via SOS (the only direct exposure of the adjusted API)

Risk

Low, only affects an API exposed to SOS (no other consumers use it). As mentioned in the PR on main, the expected number of elements in the collection when deduplicated is 1 or 2 at most, so not using a hash-table is fine for the scenario (in particular the user-reported issue will have 1 item in the collection after the fix).

IMPORTANT: If this backport is for a servicing release, please verify that:

  • For .NET 8 and .NET 9: The PR target branch is release/X.0-staging, not release/X.0.
  • For .NET 10+: The PR target branch is release/X.0 (no -staging suffix).

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

@dotnet-policy-service

Copy link
Copy Markdown
Contributor

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

@JulieLeeMSFT JulieLeeMSFT added the Servicing-consider Issue for next servicing release review label Sep 8, 2026
@JulieLeeMSFT JulieLeeMSFT added this to the 10.0.x milestone Sep 8, 2026
@JulieLeeMSFT JulieLeeMSFT added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Sep 9, 2026
@JulieLeeMSFT
JulieLeeMSFT merged commit 211c0b7 into release/10.0 Sep 9, 2026
163 of 166 checks passed
@JulieLeeMSFT
JulieLeeMSFT deleted the backport/pr-133260-to-release/10.0 branch September 9, 2026 18:18
@rbhanda rbhanda modified the milestones: 10.0.x, 10.0.13 Sep 10, 2026
naveen-devang added a commit to naveen-devang/Procure that referenced this pull request Sep 13, 2026
… x:Bind

Measured on the release build against a copy of the real database, opening and closing one PR's
detail panel 60 times: private memory 224 MB -> 155 MB, managed heap 24 MB -> 9 MB, about half the CPU
per open, handles no longer climb.

- The panel was rebuilt on every open (x:Load bound to the open flag) and WinUI never gave all of
  it back: ~1 MB and ~3 handles more per open. It is now built on the first open (FindName) and its
  Visibility follows the flag; the slide-in replays on each open.
- Its {Binding}s (and the slide-over header's) are x:Bind. A {Binding} listens through native code,
  so every PropertyChanged hands the PR to WinRT, and .NET 10.0.12's ComWrappers appends each hand-off
  to a list that is never trimmed (dotnet/runtime#133292, fixed in 10.0.13): 20 opens left 1.18
  million entries on one PR.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XY1a3Ayfsk5D1TwB3JXTin
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.

4 participants