C# capture hangs / gotchas?

I'm writing a video capture based app.
I've been writing software for many years but I'm pretty new to C# and COM.
I'm using Decklink SDK 11.4 with an Intensity Shuttle.

Short version: What concurrency gotchas should a newbie to COM be looking out for that might cause a deadlock in IDeckLinkInput.StopStreams?

I've used StillsCSharp as a base for my app; it's still early days. So far I have a preview window, overlay showing frame count, and rudimentary audio packet processing; my next step will be to record to file.

However, about one time in five, when I press Stop Capture, my app hangs. These are after short capture runs, just a few seconds long. This smells like a good old-fashioned deadlock - the entire app wedges solid, the UI unresponsive (it shows as Not Responding in Task Manager), and it doesn't come right if left for a while.

The call stack in the VS debugger shows the hang is in DeckLinkInputDevice.StopCapture(), in the call to m_deckLinkInput.StopStreams(), and below that it is in "[External Code]" which I presume is either the DeckLink DLL itself, or the COM machinery.

My instincts tell me that there's probably something really obvious I've missed in terms of threading and concurrency.

What gotchas should I be looking out for?

My app is using the multi-threaded apartment for its main thread. There doesn't appear to be a memory leak; the app is releasing video frames as soon as it is finished with them, and the VS diagnostics show process memory fluctuating a bit (~250MB during capture, with GC kicking in regularly).

Is there a debug version of the SDK available?

[Cameron Nichols]

Hi Ross,

The most likely cause for deadlock would be if you are calling IDeckLinkInput.StopStreams() method from the thread context of the IDeckLinkInputCallback.VideoInputFrameArrived callback. If so, you will need to use synchronization technique (eg with a .NET event) to move call outside of the callback

Otherwise, are you able to share call stack when you are calling StopStreams()?

Regards
Cameron

Hi Cameron

You were pretty close!

I eventually found my way around the debug views in Visual Studio. This revealed that the UI thread was calling StopStreams(), which I figured must be blocking against the DeckLink worker thread (waiting for it to join, perhaps). However, the DeckLink worker thread was itself in VideoInputFrameArrived, and thence calling a blocking invoke on the UI thread. Oops...!

I fixed it by wrapping the blocking calls up in await Task.Run blocks.

Thanks

Ross