Evaluating .NET Memory Profiler - need some assistance

[jgodfrey]

I'm currently working on a WPF-based application that allows a User to open multiple instances of a WinForms graphical control in a TabControl. The WinForms control is wrapped in a WinFormsHost-based UserControl.

For some reason, instances of the UserControl are not being released when their associated tab is closed. I've spent the better part of a day using a demo copy of .NET Memory Profiler trying to determine the root cause. From what I can tell, the problem seems to revolve around the WinFormsAdapter that contains my User Control, but I can't quite see my way through the trees.

If anyone could take a look at my saved session and give me a push in the right direction, that'd be great.

To create the session, I:

- Started my app
- Opened a single copy of my User Control in a tab
- Closed the tab
- Took snapshot #1
- Opened a new instance of my User Control
- Closed the tab
- Took snapshot #2

Comparing the snapshots, I can see that there are now 2 instances of my User control in memory. This scenario can be repeated to create additional (leaked) copies of the control.

In the referenced profiler session, the control is in the "CustomControls" namespace and is named "ViewportCustomUC".

The snapshot is here: https://www.dropbox.com/s/xz554acush2ba ... prfsession

Thanks for any assistance you can provide.

Jeff

[Andreas Suurkuusk]

If you investigate the new instance of WindowsFormsHost in your second snapshot, you will see that the instance is indirectly held by a ProcessInputEventHandler. The allocation call stack of the event handler reveals that it was created in the WindowsFormsHost constructor (via the constructor of the internal WinFormsAdapter class).

ProcessInputEventHandler holding WindowsFormsHost

Using ILSpy, you can see that WinFormsAdapter adds an event handler to InputManager.PostProcessInput, and this event handler is only removed in the Dispose method of WinFormsAdapter. So to make sure that the event is properly released, the WinFormsAdapter must be disposed (by calling WindowsFormsHost.Dispose) when you are done with your control.

I Googled "WindowsFormsHost dispose" and found an article at http://blogs.msdn.com/b/scoberry/archiv ... 35844.aspx. It contained the following information:

When mixing Windows Forms and WPF to make sure the ElementHost or WindowsFormsHost is disposed, or you could leak resources. Windows Forms will dispose an ElementHost when the non-modal Form it’s on closes; WPF will dispose a WindowsFormsHost if your application shuts down. (Really the interop-specific bit here is that you could show a WindowsFormsHost on a Window in a Windows Forms message loop and never get that your Application is shutting down.)

I hope this helps.

[jgodfrey]

Andreas,

Thanks for your informative reply. Looking at my code, when my WindowsFormsHost-based User Control was unloaded, I had specifically called Dispose() on the underlying WinForms control, but not on the WindowsFormsHost itself. Adding an additional dispose call to kill the host itself seems to have fixed the leak. Awesome!

Again, thanks so much for your input.

Jeff

[ivan_83]

Thanks for this question and answer, I also ran into the similar situation (I used ElementHost) but the problem and resolution were the same. .NET Memory Profiler rocks!