Memory Leak on UWP MediaPlayer (Windows.Media.Playback.MediaPlayer)

Question

I am maintenancing a WPF application. I added a UWP nedia player on my project. But, memory usage is too high. I realized that UWP media player did it, so I created a reproducib

Answer 1

It is absolutely a bug of Windows 10 19H1. Because built-in app (Movie and TV) has same memory leak issue. To reproduce this, just repeat that open video file and close it.

Answer 2

The way your code is written memory will bloat and grow until you run out of memory. I verified also in pure UWP. If you make the following two changes you will find that the memory will remain stable and the system will reclaim all memory after each loop:

1. Dispose also of the MediaSource object you create and assign to the Source property
2. Don't run this in a tight loop, instead invoke yourself as a dispatcher action

Here is the code (tested in UWP) that doesn't show any leak. In WPF the Dispatcher call would look slightly different:

private async void PlayMedia()
{
    var ms = MediaSource.CreateFromUri(new Uri("ms-appx:///Media1.mp4"));
    var mp = new MediaPlayer()
    {
        Source = ms
    };
    Thread.Sleep(1000);
    mp.Play();
    Thread.Sleep(1000);
    mp.Dispose();
    ms.Dispose();

    await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, new DispatchedHandler(PlayMedia));
}

As a side note: the "SomeClass" comparison you mentioned isn't exactly an apples-to-apples to comparison if SomeClass is a pure managed code class, as the objects you are creating here are complex native Windows Runtime objects that only have a thin managed code wrapper around them.

Tested also now in WPF: I reproduced the original memory growth issue, then applied the suggested changes and verified that the memory no longer grows. Here is my test project for reference: https://1drv.ms/u/s!AovTwKUMywTNuLk9p3frvE-U37saSw

Also I ran your shared solution with the WPF app packaged as a Windows App Package and I am not seeing a leak on the latest released version of Windows 10 (17763.316). Below is a screenshot of the memory diagnostics after running your solution for quite a while. If this is specific to the insider build you are running, please log a bug via Feedback Hub. I think at this point we should close this question as answered.