Unmanaged Memory Leak: CollectionView not releasing native handlers after page navigation and dynamic disposal in .NET MAUI

[MuthukumarMadasamy]

Description

When using CollectionView in .NET MAUI, unmanaged memory usage grows progressively and is not released even after the control is removed from the visual tree or the page is navigated away. This issue occurs in two scenarios:

Page Navigation: Repeatedly navigating to a page containing a CollectionView and then popping back causes unmanaged memory to increase with each iteration.
Same-Page Dynamic Disposal: Dynamically creating and removing a CollectionView on the same page also results in unmanaged memory retention.

Native platform handlers and views remain allocated even after the CollectionView is removed, indicating incomplete disposal of unmanaged resources. Over time, this leads to memory pressure and potential application crashes in long-running apps.

CollectionView.zip

Sample.zip

Without GC:

With GC:
Triggering garbage collection may slightly reduce unmanaged memory usage temporarily. However, the memory usage begins to increase again over time, indicating that native resources are not being fully released.

Steps to Reproduce

• Run attached sample.
• Open the dot memory and open this application.
• The Click Go to Page.
• Click Add CollectionView and then Click Remove CollectionView for 20 to 30 times.
• Then navigate back to main page and take snapshot in dot memory.

Link to public reproduction project repository

No response

Version with bug

9.0.110 SR12

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

No response

Did you find any workaround?

No.

Relevant log output

[HarishKumarSF4517]

This issue has been validated in Visual Studio 18.0.0 Insiders with MAUI Versions (9.0110 & 9.0.120). It was not reproduced on Windows platform. I have attached the video for reference:

Unmanaged.Memory.Leak.mp4

[sheiksyedm]

@MuthukumarMadasamy Can you confirm whether the issue still occurs after forcing a garbage collection (GC) and then taking a memory snapshot?

[MuthukumarMadasamy]

We’ve had checked with GC.Collect() the result are below.

• When calling GC.Collect() manually, managed UI elements like CollectionView, Grid, and Label are being collected and removed from memory as expected.
• However, the unmanaged memory footprint remains unaffected and in some cases, it increases after navigating back or even when staying on the same page where the CollectionView is used.
• This suggests that while the managed objects are being cleaned up, some unmanaged resources (possibly related to native handlers or platform-specific renderers) are not being released properly.

To validate this, we used JetBrains dotMemory for profiling. We’ve attached a sample project and memory snapshots/images below to illustrate the issue.

After Navigating Back:

After Call of GC:

After Calls GC managed memories are cleared. But unmanaged memories not cleared.

Sample.zip

The key concern is that unmanaged memory is not being cleared even after forcing garbage collection or navigating away from the page, which could lead to memory leaks or increased memory usage over time.
Please let us know if there’s any workaround or if this is a known issue with native handler disposal in .NET MAUI.

[sheiksyedm]

@MuthukumarMadasamy What kind of unmanaged resources related to CollectionView remain in memory after navigating back from the CollectionView page? After reviewing the memory screenshots, I was not able to identify any unmanaged or native resources directly associated with CollectionView that remain in memory after the page is navigated away.

[MuthukumarMadasamy]

Hi Team,

We used JetBrains dotMemory for profiling, which is excellent for analyzing managed memory but does not provide visibility into the exact unmanaged resources being held. The snapshots confirm that managed objects like CollectionView, Grid, and Label are properly collected after calling GC.Collect(). However, unmanaged memory remains unchanged or even increases after navigating back or removing the control dynamically.

Based on AI-assisted recommendations, the issue likely involves native handlers or platform-specific views that are not being disposed correctly. Unfortunately, dotMemory cannot show what unmanaged allocations are holding, so we cannot identify the exact resources.

Could you please advise on:

How to explicitly dispose unmanaged resources tied to CollectionView or its handlers?
Is there a recommended pattern or API for forcing disposal of native handlers in .NET MAUI?