Crash when app enter background

Hey Li, it looks like your app is crashing inside the Speech SDK’s native code when it goes into the background – specifically during a std::mutex::lock() in GetModuleObject, which usually means the SDK is trying to clean up a static/global object after the C++ runtime has started tearing down. Here are a few things to try:

1. Make sure you’re explicitly stopping and disposing all Speech SDK objects before your app enters background. • In your AppDelegate (or equivalent), implement applicationDidEnterBackground (or sceneWillResignActive) and do something like: – await recognizer.stopContinuousRecognitionAsync(); – recognizer.close(); – config = null;
2. Upgrade to the latest Speech SDK. We’ve fixed a few static-destructor race conditions in recent releases.
3. If you’re using any static/singleton wrappers around the SDK, switch to per-instance usage and dispose them cleanly on background.
4. As a workaround, you can disable the built-in module unload on exit by holding onto your main SpeechConfig/SpeechRecognizer instances until the app fully suspends.

If you’re still seeing the crash, please share:

• The exact Speech SDK version you’re on
• Your OS version/device model
• A short snippet showing how/where you initialize and tear down the recognizer
• Any other background-transition code you have

Hope this points you in the right direction!

Hi, one important update: this crash also happens when the user has not used Microsoft speech recognition in that session.

In the crash scenario, we do not create SpeechConfig, SpeechRecognizer, PushAudioInputStream, or start continuous recognition. The app only links MicrosoftCognitiveServicesSpeech-iOS through CocoaPods.

Our current version is MicrosoftCognitiveServicesSpeech-iOS 1.47.0.

The crash stack still points to Speech SDK native code, std::mutex::lock() in GetModuleObject, during background transition.

So this does not look like an active recognizer lifecycle cleanup issue on our side. Could you help confirm whether 1.47.0 has any known issue where the native framework/static module object can initialize or tear down just because the framework is linked/loaded, even without creating recognizer instances?

Also, is there a specific iOS fix in 1.48.x / 1.49.x / 1.50.x for this background/static module teardown crash? If yes, which version should we upgrade to for iOS CocoaPods?

Hi,

Thank you for the above information. I will look into this and will get back to you shortly.

Hi Li,

Thank you for the additional details — that clarification is very important.

Based on what you've described, I agree that this no longer appears to be a recognizer lifecycle cleanup issue in the application layer. The fact that the crash occurs even when no SpeechConfig, SpeechRecognizer, PushAudioInputStream, or recognition session is ever created suggests that the failure may be occurring during framework initialization or teardown within the native Speech SDK itself rather than in application-managed Speech SDK objects.

Looking at the stack trace, the crash is occurring in:

MicrosoftCognitiveServicesSpeech

GetModuleObject

std::__1::mutex::lock()

__cxa_finalize_ranges

exit

which indicates the failure is happening during native runtime cleanup while the process/framework is being torn down, rather than during an active recognition operation. The crash location is consistent with a native module/static-object cleanup path.

At this time, I am not aware of publicly documented release notes that specifically call out a fix for a GetModuleObject / std::mutex::lock() crash during iOS background transition or static module teardown. The Speech SDK release notes for 1.48.x–1.50.x mention several fixes, but none explicitly reference this scenario.

Nevertheless, since you are currently using MicrosoftCognitiveServicesSpeech-iOS 1.47.0, I would strongly recommend validating whether the issue reproduces with the latest available Speech SDK version (currently 1.50.x), as a number of native stability fixes have been included across subsequent releases.

To help determine whether this is an SDK-level issue, could you also share:

• iOS version(s) where the crash is observed
• Whether the Speech SDK is linked as a dynamic framework or static XCFramework
• Whether Crashlytics (or another symbolication tool) consistently shows the same GetModuleObject → std::mutex::lock() call path
• A full symbolicated crash report if available

If the issue can be reproduced on the latest SDK release and still occurs without any Speech SDK object creation, we can engage the Speech SDK engineering team for deeper investigation, as that would indicate the crash may be occurring solely due to framework load/unload behaviour rather than application usage.

Thanks for providing the additional context, and I look forward to your findings.