Search Issue Tracker
Third Party Issue
Votes
0
Found in
2022.2.5f1
Issue ID
UUM-47253
Regression
Yes
Crash on il2cpp::os::SynchronizationContext::GetForCurrentThread when built in batch mode and SynchronizationContext not set on thread
Reproduction steps:
1. Launch the attached Player “CrashRepro“ in Batch mode
Expected result: Player does not crash
Actual result: Player crashes
Reproducible with: 2022.2.5f1
Not reproducible with: 2022.2.4f1
Reproducible on: Windows 10
Not reproducible on: No other environment tested
First few lines of stack trace:
{noformat}0x00007FFDB7AF96F8 (GameAssembly) il2cpp::os::SynchronizationContext::GetForCurrentThread
0x00007FFDB7AB651B (GameAssembly) il2cpp::icalls::mscorlib::System::Threading::OSSpecificSynchronizationContext::GetOSContext
0x00007FFDBA49165F (GameAssembly) OSSpecificSynchronizationContext_GetOSContext_mDC8E96412452C2C1EBEB8277CB2B075384A3D1E5
0x00007FFDBA49171D (GameAssembly) OSSpecificSynchronizationContext_Get_mC3473B9DD7959166E55F9845FCB1EA2C94AB0B86
0x00007FFDBA496143 (GameAssembly) SynchronizationContext_GetThreadLocalContext_m8805737DDE19D41FC34F35BBE13097C189CD1105 {noformat}
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Sprite Masks affect Sprite Renderers outside their range when a Light2D is present with specific Target Sorting Layers selected
- URP Lens Flare is rendered in the wrong position when Render Graph Compatibility Mode is enabled and Render Scaling is not 0
- Editor crashes on DrvPresentBuffers when loading RenderDoc while using OpenGLES 3.0 or OpenGLES 2.0 Graphics API
- [Test Runner] Incorrect name under Window > Panel after project restart
- [iOS] Crash when using fallback fonts created at runtime
Resolution Note:
The crash happens because one of the native plugins in the project calls combase.dll!CoUninitialize without a matching prior call to combase.dll!CoInitializeEx, which causes COM to be shut down in the process and that unloads all COM related DLLs. One of those DLLs COM unloads is CoreMessaging.dll, which s_DispatcherQueueStatics (the variable that causes a crash when accessed) is based in and thus causing calling any methods on it access an already freed VTable.
To fix this issue, either:
1. Modify the native plugin that calls CoUninitialize to call CoInitializeEx first;
2. Modify the native plugin to not call CoUninitialize at all;
3. Call CoInitializeEx manually before calling into the native plugin.