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
- GC.Alloc called by HDRenderPipeline.LensFlareMergeOcclusionDataDrivenPass() when playing the default HDRP Sample Template project
- Automatic LOD fails and SRP Batcher incompatibility occurs when using spline-based quad-topology meshes
- Editor crashes on D3D12GetInterface when repeatedly enabling and disabling 256 text components
- Flickering bright white dots in the Scene when the Android Platform is selected and DX11 Graphics API is used with Iris(R) Xe Graphics GPU
- Inconsistent capitalization and misaligned text in multiple query blocks in Search window
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.