Suspect memory leak related to RichTextBox on .Net 10.0.102

[carltonshen-work]

.NET version

10.0.102

Did it work in .NET Framework?

Not tested/verified

Did it work in any of the earlier releases of .NET Core or .NET 5+?

Same code has no issue with .Net 8.0.

Issue description

I have a simple WinForm application which redirects console input/output and uses a RichTextBox for colored output.

When the program is compiled with .Net 10, it will accumulate about 10MB of memory usage every hour. Below is the GC Dump I've captured:

net10.202601161100.zip

And below is the PerfView top items for the Heap Stack view:

Name	Exc %	Exc	Exc Ct	Inc %	Inc	Inc Ct	Fold	Fold Ct
LIB <<System.Private.CoreLib!List<Runtime.InteropServices.ComWrappers+ManagedObjectWrapperHolder>>>	97.7	33,555,208	14	97.7	33,555,208	14	33,554,984	7
LIB <<System.Private.CoreLib!Diagnostics.Tracing.NativeRuntimeEventSource>>	0.6	199,730	2,457	0.6	199,730	2,457	198,886	2,443
LIB <<System.Diagnostics.Process!Diagnostics.Process>>	0.3	113,488	74	0.3	113,488	74	109,136	14
LIB <<System.Diagnostics.DiagnosticSource!Diagnostics.Metrics.MetricsEventSource>>	0.2	61,242	537	0.2	61,242	537	58,846	499
[local vars]	0.2	60,104	139	0.3	91,345	637	60,104	138
(more lines ignored)

However, if it is compiled with .Net 8.0, its memory usage is stable over time.

Steps to reproduce

Below is the procedure that is being repetitively called to add text to the RTB:

    private void AppendLineToConsoleWithColor(string text, Color color)
    {
        if (consoleOutput.InvokeRequired)
        {
            consoleOutput.Invoke(AppendLineToConsoleWithColor, text, color);
            return;
        }

        consoleOutput.SelectionStart = consoleOutput.TextLength;
        consoleOutput.SelectionLength = 0;
        consoleOutput.SelectionColor = color;

        consoleOutput.AppendText(text);
        consoleOutput.AppendText(Environment.NewLine);
        currentConsoleCharCount += text.Length;
        currentConsoleCharCount += Environment.NewLine.Length;

        consoleOutput.SelectionColor = consoleOutput.ForeColor;

        if (currentConsoleCharCount > loadedConfig.Settings.MaxConsoleChars)
        {
            int removeUpTo = consoleOutput.Text.IndexOf('\n', loadedConfig.Settings.TrimChunkSize);
            if (removeUpTo > 0)
            {
                Win32WindowAPI.SuspendRedraw(consoleOutput.Handle);
                try
                {
                    consoleOutput.Select(0, removeUpTo + 1);
                    consoleOutput.ReadOnly = false;
                    consoleOutput.SelectedText = string.Empty;
                    consoleOutput.ReadOnly = true;
                    consoleOutput.ClearUndo();
                }
                finally
                {
                    Win32WindowAPI.ResumeRedraw(consoleOutput.Handle);
                }
                currentConsoleCharCount = consoleOutput.TextLength;
            }
        }
    }

I believe anything that add text to RTB would trigger the same issue. I can already confirm the Win32 API call on the SuspendRedraw and ResumeRedraw is irrelevant, that remove them does not make any difference.

I have a test app that generates text continuously so the above code is called frequently, which I believe anything to the same effect will work.

[ricardobossan]

@carltonshen-work

Thank you for reporting this issue.

We attempted to reproduce the memory leak based on the code snippet you provided, but were unable to observe the behavior you described.

Our reproduction steps:

1. Created a WinForms application targeting net10.0-windows
2. Implemented the AppendLineToConsoleWithColor method as shown in your snippet
3. Set up a timer to call this method repeatedly (every 50ms)
4. Ran the application for 3 hours, taking GC dumps at intervals using dotnet-gcdump

Our results:

Snapshot 1 (1 min):   405,706 bytes, 5,284 objects
Snapshot 2 (30 min):  405,762 bytes, 5,288 objects
Snapshot 3 (3 hours): 406,026 bytes, 5,310 objects

ManagedObjectWrapperHolder: 1 instance (unchanged across all snapshots)

Memory remained stable throughout the test. The ManagedObjectWrapperHolder type you identified in your PerfView dump stayed at 1 instance.

To help us investigate further, could you please provide:

• A minimal sample project that reproduces the issue (the complete solution, not just the code snippet)
• The exact .NET SDK version you are using (dotnet --version)

We are attaching the text-converted reports from the gcdump snapshots, and the zipped source code we used for testing.

Thanks again for taking the time to report this.

report3.txt
WinFormsApp2.zip
report1.txt
report2.txt

[carltonshen-work]

@ricardobossan Thanks for the follow up. I've prepared a stripped-down project which I have confirmed to replicate this issue.

This is the package:
ShellExecutor_net10_leak_test.zip

In there, you can find my project code. There are 3 gcdump files, from different runs (on slight variance of the code) that confirms the leak exists. I've included the obj and bin folder in case there's some useful information for you to investigate.

Just run dotnet build to build it and get an executable that would trigger the issue. I have tried release build, which results in a similar result.

My local dotnet version is:

> dotnet --version 
10.0.102

And here's all the net10 packages I've installed on the dev box via chocolatey:

dotnet-10.0-aspnetruntime 10.0.1
dotnet-10.0-desktopruntime 10.0.1
dotnet-10.0-runtime 10.0.1
dotnet-10.0-sdk 10.0.101
dotnet-10.0-sdk-1xx 10.0.101

Sorry that I haven't checked your code - because it takes hours to confirm issue and strip-down code is done gradually, I think start from my code would allow me to provide an update sooner.

[ricardobossan]

@carltonshen-work Thank you for providing the sample project and gcdump files.

We tested your ShellExecutor sample with .NET SDK 10.0.102 (pinned via global.json) and took GC dumps at intervals over 3 hours:

Snapshot 1 (1 min):  195,160 bytes, 2,316 objects
Snapshot 2 (30 min): 193,772 bytes, 2,308 objects
Snapshot 3 (3h):     178,212 bytes, 2,304 objects

ManagedObjectWrapperHolder: 1 instance → 1 instance → 0 instances

Memory remained stable and actually decreased slightly over time. We could not reproduce the leak.

We also analyzed the gcdump files you provided:

test02 (12:19): 16.9 MB total
test03 (13:11): 1.2 MB total
test04 (13:57): 708 KB total

These also show memory decreasing over time, not increasing.

To help us understand the discrepancy, could you clarify:

1. How are you measuring the memory growth? (GC heap via gcdump/PerfView, or process memory via Task Manager?)
2. Are test02/test03/test04 sequential snapshots of the same running process, or separate test runs?
3. Does your actual application have additional components beyond what's in the ShellExecutor sample?

We are attaching our gcdump snapshots and text reports for reference.

Thanks again for your patience.

author_snap1.txt

author_snap2.txt

author_snap3.txt

[carltonshen-work]

Thanks @ricardobossan again for the follow up.

It feels like probably an environment issue now. I've already started the test on a different system, should have an update a few hours later.

From my previous zip package, 202601231357.net10.test04.gcdump is captured with the exact bin found as ShellExecutor_net10_leak_test.zip\ShellExecutor\bin\x64\Debug\net10.0-windows\win-x64\ShellExecutor.exe, after running a few hours. And the bin is compiled using the exact code contained in the zip file.

From there, 202601231219.net10.test02.gcdump and 202601231311.net10.test03.gcdump are from different runs on different binary which is not in the package, but the code difference is minor. I am basically removing unreferenced stuff from the code gradually, and these 2 are generated as interim results.

I noticed the issue from monitoring its working set size from Task Manager. The purpose of this application (the original version) was to control and monitor resource usage, so it came to my notice that its memory footprint grows indefinitely although not very fast. And thus a GC dump is captured to help analyze the reason.

The original version of the application has a bunch of more features, but the minimal version which is the exact code and binary in the zip file could reproduce the issue I've seen.

And just to repeat myself on why I think this is a .Net 10 issue, the same code (both the minimal version and the full original version) compiled on .Net 8.0 does not show the same issue. No working set growing indefinitely, and no large amount of LIB <<System.Private.CoreLib!List<Runtime.InteropServices.ComWrappers+ManagedObjectWrapperHolder>>> from GC dump.

[carltonshen-work]

@ricardobossan I've tried the same binary on a different computer and it showed the exact same behavior.

Here's the GC Dump:
test05.gcdump.zip

Although there's not much of a difference between the systems. Both Windows 11 25H2, .Net 10 version also 10.0.102. Hardware-wise they are somewhat different, on different gens of Intel platform.

I will try find a system that is more different to further confirm this.

[ricardobossan]

@carltonshen-work Thanks for the additional details and the test05 dump.

One clarification about your build process: your csproj has <PublishAot>true</PublishAot>, but you mentioned running the binary from bin\x64\Debug\net10.0-windows\win-x64\ShellExecutor.exe.

AOT compilation only activates with dotnet publish, and the output goes to a publish\ subfolder. A regular dotnet build or dotnet run produces a JIT-compiled binary instead.

Could you confirm:

1. How did you build the binary you tested? (dotnet run, dotnet build, or dotnet publish?)
2. If you used dotnet publish, did you have to suppress the WinForms trim error? (We encountered NETSDK1175: Windows Forms is not supported or recommended with trimming enabled)
3. Is the exe you're running from bin\...\win-x64\ or bin\...\win-x64\publish\?

This will help us match your exact build configuration.

[carltonshen-work]

@ricardobossan Right I should have made the clarification regarding AOT - yes, originally I wanted to enable AOT, but just like you said it was not working without publish, also requires some extra setup which I haven't really figured out. So that setting is effectively turned off and unrelated to this whole situation.

I did mention AOT in my original post but then I realized it was not relevant, so I've got that edited out.

The binary is built with dotnet build, and it goes to Debug profile by default, without AOT.
dotnet publish should not work - and like I mentioned above, it should be irrelevant to this issue.
I am running the exe from .\bin\x64\Debug\net10.0-windows\win-x64\. Which I believe is also the only exe in the zip package.

I also want to mention that build with Release does not change the behavior.

[ricardobossan]

@carltonshen-work Thanks for clarifying the build process.

We had previously tested your sample project using dotnet run:

Test 1: dotnet run

Snapshot 1 (1 min):  195,160 bytes, 2,316 objects
Snapshot 2 (30 min): 193,772 bytes, 2,308 objects
Snapshot 3 (3h):     178,212 bytes, 2,304 objects

After your clarification, we ran a new test matching your exact workflow, running the exe directly from the build output:

Test 2: Running exe directly from bin\x64\Debug\...\

Snapshot 1 (1 min): 220,456 bytes, 2,407 objects
Snapshot 2 (1h):    180,556 bytes, 2,383 objects
Snapshot 3 (3h):    214,438 bytes, 2,427 objects

In both cases, memory remained stable or decreased. We could not reproduce the leak.

We are using:

• Windows 11
• .NET SDK 10.0.102
• Your exact ShellExecutor sample project
• Both dotnet run and direct exe execution

Since you mentioned reproducing the issue on two different computers, could you share any details about your environment that might differ from ours?

• Any third-party software that interacts with .NET or Windows Forms?
• Any specific Windows settings or group policies?
• Are both machines physical or is one a VM?
• Output of dotnet --info (full runtime/SDK details)
• Any other info you might find helpful

We want to understand what environmental factor might be causing the difference.

[carltonshen-work]

@ricardobossan Here's all the computer platforms I've tried on:

• My personal laptop, ThinkPad Intel 13th gen, Windows 11 25H2, newest updates
• My work laptop, ThinkPad Intel 11th gen, Windows 11 25H2, newest updates
• A dev server, Dell server, Intel i9 9th gen, Windows 11 22H2, newest updates
  On all of them I can replicate the same issue.

GC dump for the 3rd one (the dev server) with the same binary from my zip file is here:
test06.zip

This basically exhausts the variety of platform I have access to. I actually tried it on 2 more work laptops, same result. But they are essentially the same configuration as my work laptop so there's not much information provided.

And to answer your questions:

• No third-party software that I am aware of. Between the different platforms, my personal laptop does not have enterprise monitoring stuff, and the server does not have most of the desktop software applications. I think they share only the .Net 10 SDK, Teams and a bunch of Windows internal stuff, and the binary of course.
• Because of the variety, I think there are only a bunch of stock settings are the same. Probably also that they all use ISO clock. Otherwise they should differ a lot from each other.
• All physical machines.
• I will attached the result from each of them at the end.
• Nothing really - I probably will try a Win10 VM later once I can get it setup. But otherwise I think my samples has a lot of variety to rule out a lot of possibilities.

If you have some other tools for me to capture some more useful diagnostic information, please do let me know.

And here's the dotnet --info outputs:
From my personal laptop:

> dotnet --info
.NET SDK:
 Version:           10.0.102
 Commit:            4452502459
 Workload version:  10.0.100-manifests.73000c7b
 MSBuild version:   18.0.7+445250245

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26200
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.102\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.2
  Architecture: x64
  Commit:       4452502459

.NET SDKs installed:
  5.0.100 [C:\Program Files\dotnet\sdk]
  9.0.310 [C:\Program Files\dotnet\sdk]
  10.0.102 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

And my work laptop:

> dotnet --info
.NET SDK:
 Version:           10.0.102
 Commit:            4452502459
 Workload version:  10.0.100-manifests.73000c7b
 MSBuild version:   18.0.7+445250245

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26200
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.102\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.2
  Architecture: x64
  Commit:       4452502459

.NET SDKs installed:
  7.0.410 [C:\Program Files\dotnet\sdk]
  8.0.303 [C:\Program Files\dotnet\sdk]
  8.0.417 [C:\Program Files\dotnet\sdk]
  9.0.205 [C:\Program Files\dotnet\sdk]
  9.0.310 [C:\Program Files\dotnet\sdk]
  10.0.102 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

And the dev server:

> dotnet --info
.NET SDK:
 Version:           10.0.102
 Commit:            4452502459
 Workload version:  10.0.100-manifests.73000c7b
 MSBuild version:   18.0.7+445250245

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.102\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.2
  Architecture: x64
  Commit:       4452502459

.NET SDKs installed:
  10.0.102 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download