UnmanagedMemory leak when disposing a WindowsFormsHost

Question

We are currently reworking a WindowsForms application in WPF. The software is quite large and it will take years to finish it, so we have a hybrid system that displays pure WPF for the new panels and Hosted WindowsForms elements in WindowsFormsHosts controls. We use Syncfusion's WPF Docking Manager to show these pages in tabs (not sure that this info is relevant). We spent quite a lot of time to track down memory leaks (using JetBrains' DotMemory), but we run out of memory after opening and closing nearly 100 pages containing WindowsFormsHosts.

This memory leak is quite strange, as you can see in the memory profiling, it seems that the problem lies in the unmanaged memory.

DotMemory profiling

The WindowsFormsHosts seem to be correctly disposed as well as the Child content. As suggested here WPF WindowsFormsHost memory leak, we wrap the WindowsFormsHosts in a grid that we clear when we want to dispose it:

public override void Dispose()
{
    if (this.Content is Grid grid && grid.Children.Count == 1)
    {
        if (grid.Children[0] is KWFHost wfh)
        {
            wfh.Child.SizeChanged -= ControlSizeChanged;
            wfh.Dispose();
        }

        grid.Children.Clear();
    }

    base.Dispose();
}

and

public class KWFHost : WindowsFormsHost
{
    protected override void Dispose(bool disposing)
    {
        if (this.Child is IDisposable disposable)
        {
            disposable.Dispose();
        }

        this.Child = null;
            
        base.Dispose(true);
    }
}

We suspect that the Hosting causes the leak because in DotMemory, in memory allocation we can see this:

memory allocation

Is there any known issue with the WindowsFormsHosts that could explain this? Or a way for us to isolate the source of the problem?

Edit : Here is the code that adds the Grid and WindowsFormHost :

public void SetContent(System.Windows.Forms.Control control)
{
    var host = new KWFHost();
    host.Child = control;
    control.SizeChanged += ControlSizeChanged;

    var grid = new Grid();
    grid.Children.Add(host);

    this.Content = grid;
}

Answer 1

I finally figured it out: After a bit more digging, I found out that the WindowsFormsHosts are kept alive. DotMemory gives me two reasons for that.

• the first one: System.Windows.Interop.HwndSourceKeyboardInputSite. For a reason that I can't explain, there is still a reference to the WindowsFormsHost in the ChildKeyboardInputSinks in the HwndSource. If someone knows why, I'd be interested in hearing the reason. I don't know if there is a better way to get rid of this reference, but here's the code I wrote:

private void CleanHwnd(KWFHost wfh) //my implementation of WindowsFormsHost
{
        HwndSource hwndSource = PresentationSource.FromVisual(wfh) as HwndSource;

        //here I isolate the right element to remove based on the information I have
        IKeyboardInputSink elementToRemove = hwndSource.ChildKeyboardInputSinks.FirstOrDefault(c => c is KWFHost h && h.Parent is Grid g && g.Parent is KWindowsFormsHost fh && Equals(fh.TabName, TabName));

        //The method CriticalUnregisterKeyboardInputSink takes care of removing the reference but as it's protected I use reflection to get it.
        var mi = typeof(HwndSource).GetMethod("CriticalUnregisterKeyboardInputSink",
            BindingFlags.NonPublic | BindingFlags.Instance);

        //here I remove the reference
        mi.Invoke(hwndSource, new object[] { elementToRemove.KeyboardInputSite });
}

I execute this method just before disposing the WindowsFormsHost.

• The second reason was RootSourceRelationManager. This one gave me a headache. So I did a "Full" dotmemory profiling (before it was a sampled one). The result was strange, the memory leak disappeared. The full profiling needs to be executed from Dotmemory and not from Visual Studio. That was the only difference. After some research I found out that Microsoft.Visual.Design Tools.WpfTap.wpf was involved. So it seems (I can't be sure) that executing from visual studio causes a memory leak (which is not that serious but a good thing to know).

In the end, after releasing a new test version of the software with the clean method, I no longer have a memory leak.