Stack buffer overrun error in GraphicsCapture.dll when closing a capture session while multiple captures are active (Windows 10 1809)

[elvissteinjr]

As the title suggests, I've run into an issue with multiple captures running at once in a single process. But only on Windows 10 1809 (and perhaps earlier), not later.
To be sure I've gone ahead and checked this with fresh VMs of 1809, 1903, 1909, 2004 and 20H2 as well. It only crashes on the 1809 systems (real and VM).
From what I've read this is probably just GraphicsCapture.dll doing a fail-fast instead of a real buffer overrun, but I'm not really an expert on that subject... it crashes, let's say that.

I've had this issue before when just trying to stop a capture, but was able to seemingly circumvent it by adding a short sleep between closing the session and the frame pool. Now that I want to restart the capture on the fly sometimes as a workaround for #26, this proved to be not actually that reliable once a new session was to be set up again right away. Even worse is a situation with two captures on the same target, where such a restart would be triggered twice at the same time, which almost always causes the crash on 1809.

Supporting 1809 likely doesn't make much sense anymore, but I don't like dropping support for no reason either. That aside, I thought I should rather make sure I'm not doing something terribly wrong and newer versions just swallow up my mistake here.

I've forked this repo and modified it to spawn two captures instead of just one, using the same capture item (different ones have the same effect, though). The "Take Snapshot" button was turned into a "Restart Capture" button. The crash can be triggered as long as the CaptureFrame is retrieved in the FrameArrived event, even if it's not doing anything and just releases the frame right away.
Pressing the "Restart Capture" button a couple of times is a surefire way to crash the application on the affected OS versions, but simply using Stop Capture works as well, just more rarely.
The repo is here: https://github.com/elvissteinjr/Win32CaptureSample
While that's not exactly how I'm implementing it in the real project, it's a minimal modification that has the same effect.

Am I doing something terribly wrong? Are there some extra multithreaded considerations to be applied here (but frames are all arriving on the same thread through the DispatcherQueue, aren't they?)? Or is this just something that got fixed in later versions of Windows and I'll have to deal with it? I've seen the ID3D11Multithread recommendation on the C# sample, but that's not helping here.

Oh and in the real project it's one thread per capture. Everything seems to be working fine apart from this issue so I doubt it, but I don't need to synchronize access to the Graphics Capture API when every thread is working with its own set of data, do I?

Thank you for your time. This one's been kind of a bother.

[robmikh]

I'll take a closer look after the holidays, but this sounds like a bug that was fixed after version 1809. The releases have blurred together a bit so I can't exactly remember when I fixed this.

You're likely not doing something wrong. I'll see what options we have here, but it looks like version 1809 hit end of servicing:
https://docs.microsoft.com/en-us/lifecycle/announcements/windows-10-1809-end-of-servicing