Race conditions in various WASAPI audio examples during deinitialization/Stop() functions.

Example, in
https://github.com/microsoft/Windows-classic-samples/blob/main/Samples/ApplicationLoopback/cpp/LoopbackCapture.cpp

HRESULT CLoopbackCapture::OnStopCapture(IMFAsyncResult* pResult)

It seems to me like there's no thread safety. The device state m_DeviceState writes are made without any sort of thread safety. None of the OnStopCapture or OnFinishCapture are happening in any either thread safe manner - they might be writing to things that OnSampleReady doing simultaneously (one simple solution would be to run these OnStop/OnFinish on the same worker queue as OnSampleReady and also make that queue serial.

There's also no real way to tell if it's safe to destroy a CLoopbackCapture object - should we not wait until all the jobs have finished before we allow destruction of a CLoopbackCapture?

I'm not an experienced windows developer so I might be missing something, sorry if that's the case.

Start with Samples/ApplicationLoopback/cpp/LoopbackCapture.cpp, reading OnStopCapture, OnFinishCapture, and OnSampleReady together with the capture object's destruction path. Trace how m_DeviceState and queued work are accessed during Stop and deinitialization. Done means the involved examples have a defined, race-free stop and destruction lifecycle.