You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I encountered a memory leak issue with our components. During my research, I found that the key issue is caused by System.Windows.Automation.Peers.ItemsControlItemAutomationPeer.
It holds a reference to the user control (ViewA) via the field _itemsControlAutomationPeer.
How it works:
We use a ContentControl and two views — ViewA and ViewB.
On a button click, I change ContentControl.Content to a new instance of the view.
In this case, I expect that the previous instance of the view (ViewA) should be collected, because it has been unloaded from the visual tree.
And this works until I start showing any popups.
At that moment, setting the new RootVisual causes the EnsureAutomation call.
This method forces the creation of the automation tree, and from that moment on, ItemsControlItemAutomationPeer holds a reference to ViewA.
Now, I’m looking for any help, solution, or workaround.
This is just a test sample, but we have a real-world scenario where our customer is suffering from this issue.
YES.
Under NET 6, it can't be reproduced, but there is another memory leak here (it is caused by AutomationPeer. _children.
I also tried to reproduce it under Framework 4.8, but it works properly without leaks
Known Workarounds
No response
Impact
No response
Configuration
WPF NET 9. This issue can be reproduced under NET 8 and higher.
Other information
No response
The text was updated successfully, but these errors were encountered:
Description
Hello, I encountered a memory leak issue with our components. During my research, I found that the key issue is caused by
System.Windows.Automation.Peers.ItemsControlItemAutomationPeer
.It holds a reference to the user control (
ViewA
) via the field_itemsControlAutomationPeer
.How it works:
ContentControl
and two views —ViewA
andViewB
.ContentControl.Content
to a new instance of the view.ViewA
) should be collected, because it has been unloaded from the visual tree.And this works until I start showing any popups.
At that moment, setting the new
RootVisual
causes the EnsureAutomation call.This method forces the creation of the automation tree, and from that moment on,
ItemsControlItemAutomationPeer
holds a reference toViewA
.Now, I’m looking for any help, solution, or workaround.
This is just a test sample, but we have a real-world scenario where our customer is suffering from this issue.
Reproduction Steps
MemoryLeakTestApp
ShowPopup
a couple of timesChangeView
ViewA
MemoryLeakTestApp.zip
Expected behavior
The
ViewA
should be collected by the GCActual behavior
The
ViewA
remains in memoryRegression?
YES.
Under NET 6, it can't be reproduced, but there is another memory leak here (it is caused by
AutomationPeer. _children
.I also tried to reproduce it under Framework 4.8, but it works properly without leaks
Known Workarounds
No response
Impact
No response
Configuration
WPF NET 9. This issue can be reproduced under NET 8 and higher.
Other information
No response
The text was updated successfully, but these errors were encountered: