microsoft/Windows.UI.Composition-Win32-Samples

Memory Leak?

BenShapira opened this issue · 5 comments

BenShapira commented

Hey, Trying to use this sample repo (dotnet-wpf : https://github.com/microsoft/Windows.UI.Composition-Win32-Samples/tree/master/dotnet/WPF/ScreenCapture) for screen-capturing multiple windows in a loop.
It seems like every time I start->stop a capture a memory is being held, and it keeps ramping up.
A sample example to reproduce this issue would be -

            while (true)
            {
                foreach (var window in _selectedWindows)
                {
                    GraphicsCaptureItem item = CaptureHelper.CreateItemForWindow(window.WindowHandler);

                    _screenshotService.StartCaptureFromItem(item);
                    await Task.Delay(100);
                    _screenshotService.StopCapture();

                }
                await Task.Delay(TimeSpan.FromSeconds(3));
            }

App memory starts at 80MB, and within a minute or so it's already at 1GB.
Stopping this loop after it accumulated some memory doesn't release the memory as well.

Any tips on how to achieve my requirements without using unlimited amounts of memory?
Thanks

robmikh commented

Are you calling Dispose on both the GraphicsCaptureSession and Direct3D11CaptureFramePool each time you capture? Does the memory usage change if you force the GC to run? What else are you doing in your service object?

BenShapira commented

Hey Rob, thanks for responding.
my _screenshotService is what's called in the repo as BasicSampleApplication -

Windows.UI.Composition-Win32-Samples/dotnet/WPF/ScreenCapture/CaptureSampleCore/BasicSampleApplication.cs

Line 34 in ee50e2e

public class BasicSampleApplication : IDisposable

Calling StopCapture does -

        public void StopCapture()
        {
            capture?.Dispose();
            brush.Surface = null;
        }

Which is calling the disposal of the capture that is doing -

        public void Dispose()
        {
            session?.Dispose();
            framePool?.Dispose();
            swapChain?.Dispose();
            d3dDevice?.Dispose();
        }

Profiling my app does show an increase of 78 Direct3D11FramePool objects in a span of a couple of minutes, so maybe they aren't actually being disposed and I keep getting new frames for every instance of those frame pools?
How would you recommend forcing the GC to kill them?

robmikh commented

System.GC.Collect will force the garbage collector to run. I wouldn't use it in production code but it can be useful to see if the runtime is just hoarding memory or if you really have a leak.

That application class is not meant to be created multiple times. You are creating a ton of D3D devices each time, I would refactor the code to accept a D3D device instead and reuse the same device across all captures.

Oops, I misread your snippet.

BenShapira commented

I forgot I've added a screenshot capability to the service, where it basically saves the first captured frame into a CpuTexture,
That I (sadly) forgot to add to the dispose method, so every time I started a new capture session I also added a CpuTexture that I didn't dispose of... (therefore using System.GC.Collect didn't release any memory...)

Forgive my mistake, thanks for helping out.
I'll close this issue.
As this was simply a mistake on my part, feel free to delete this issue completely to avoid confusing others.

Cheers

robmikh commented

No worries! I'm glad you got things sorted out.

  • 🚀1