UE5.4.1 PIE session stuck when trying to kill the AudioRenderThread

I recently upgraded from 5.3.1 to 5.4 and then 5.4.1 and I noticed that my PIE sessions keep on getting stuck when I close them. I traced it to:

void IAudioMixerPlatformInterface::StopGeneratingAudio()
{		
	SCOPED_NAMED_EVENT(IAudioMixerPlatformInterface_StopGeneratingAudio, FColor::Blue);

	// Stop the FRunnable thread

	if (AudioStreamInfo.StreamState != EAudioOutputStreamState::Stopped)
	{
		AudioStreamInfo.StreamState = EAudioOutputStreamState::Stopping;
	}

	if (AudioRenderEvent != nullptr)
	{
		// Make sure the thread wakes up
		AudioRenderEvent->Trigger();
	}

	if (AudioRenderThread.IsValid())
	{
		{
			SCOPED_NAMED_EVENT(IAudioMixerPlatformInterface_StopGeneratingAudio_KillRenderThread, FColor::Blue);
			AudioRenderThread->Kill();
		}

Being on Windows, here is the code called to kill the thread:

	virtual bool Kill(bool bShouldWait) override
	{
		check(Thread && "Did you forget to call Create()?");
		bool bDidExitOK = true;

		// Let the runnable have a chance to stop without brute force killing
		if (Runnable)
		{
			Runnable->Stop();
		}

		if (bShouldWait == true)
		{
			// Wait indefinitely for the thread to finish.  IMPORTANT:  It's not safe to just go and
			// kill the thread with TerminateThread() as it could have a mutex lock that's shared
			// with a thread that's continuing to run, which would cause that other thread to
			// dead-lock.  
			//
			// This can manifest itself in code as simple as the synchronization
			// object that is used by our logging output classes

			WaitForSingleObject(Thread, INFINITE); // <--
		}

It looks like the AudioRenderThread might have a stuck mutex, but i’m not sure how to debug further.

@lantz.anna_1 let me know if there is anything I can do to help.

I removed some submixes and force feedback and the issue doesn’t happen as often, Is there a way to observe mutexes on the audio render thread to debug those kind of issues?