Split out of #264, which pooled six crash dumps that turned out to be at least three distinct bugs.
Reported by a partner integrator (Amazon Lab126 / LeiaViewer port, internal ticket UNITY-133).
Signature — dump folder Crash_2026-09-01_0244
Unlike #264 this one has a full Unity stack trace in the adjacent Editor.log:
========== OUTPUTTING STACK TRACE ==================
UnityEngine::PlatformWrapper::GetRenderingResolution
UnityEngine::Analytics::DeviceInfoEvent::CollectExtraInfo
UnityEngine::Analytics::DeviceInfoUpdater::LookForAppChanges
BaseUnityAnalytics::LookForVersionChange
BaseUnityAnalytics::OnEnterStateStarted
UnityEditorCoreStats::OnEnterStateStarted
BaseUnityAnalytics::RequestStateChange
BaseUnityAnalytics::DonePreparingOnMainThreadStatic
BackgroundJobQueue::ExecuteMainThreadJobs
EarlyUpdateExecuteMainThreadJobsRegistrator::Forward
Application::TickTimer
MainMessageLoop
UnityMain
========== END OF STACKTRACE ===========
13 frames, flat. No mono frames. No recursion, no repetition. Grepping the whole log for stack overflow|StackOverflow|recursion|Insufficient stack returns zero hits.
Why this is not #264
#264 is a genuine main-thread stack overflow (rsp == StackLimit, a 7,344-byte frame pair repeating, fault in mono-2.0-bdwgc.dll). This crash has none of those properties. Treating them as one signature is what made both harder to reason about, and the reasoning that applies to one does not transfer.
The interesting part, stated as an observation and not a mechanism
Unity's analytics subsystem crashes inside GetRenderingResolution, called from a main-thread job — on a box where a DisplayXR session had been changing the render target.
That is a plausible interaction point: the provider drives an arraySize=2 swapchain and reallocates the eye bridge when the pane geometry changes, and Unity's analytics reads rendering resolution on a schedule of its own, unsynchronised with any of it.
It is Unity's code on Unity's stack, so this is a correlation worth recording, not a diagnosis. Specifically:
- No DisplayXR frame appears on the stack.
- Nothing establishes that the crash requires a DisplayXR session at all — it may simply be a Unity bug that this rig happens to hit.
Note for anyone applying #264's conclusions here: the render-target / native layer is not ruled out for this crash. The argument that killed the native hypotheses in #264 ("a native realloc bug does not produce repeating managed frames") depends on the repeating managed frames, and this dump has no managed frames at all.
Needed to progress
Related: #264 (main-thread stack overflow, the same dump batch).
Split out of #264, which pooled six crash dumps that turned out to be at least three distinct bugs.
Reported by a partner integrator (Amazon Lab126 / LeiaViewer port, internal ticket UNITY-133).
Signature — dump folder
Crash_2026-09-01_0244Unlike #264 this one has a full Unity stack trace in the adjacent
Editor.log:13 frames, flat. No mono frames. No recursion, no repetition. Grepping the whole log for
stack overflow|StackOverflow|recursion|Insufficient stackreturns zero hits.Why this is not #264
#264 is a genuine main-thread stack overflow (
rsp == StackLimit, a 7,344-byte frame pair repeating, fault inmono-2.0-bdwgc.dll). This crash has none of those properties. Treating them as one signature is what made both harder to reason about, and the reasoning that applies to one does not transfer.The interesting part, stated as an observation and not a mechanism
Unity's analytics subsystem crashes inside
GetRenderingResolution, called from a main-thread job — on a box where a DisplayXR session had been changing the render target.That is a plausible interaction point: the provider drives an
arraySize=2swapchain and reallocates the eye bridge when the pane geometry changes, and Unity's analytics reads rendering resolution on a schedule of its own, unsynchronised with any of it.It is Unity's code on Unity's stack, so this is a correlation worth recording, not a diagnosis. Specifically:
Note for anyone applying #264's conclusions here: the render-target / native layer is not ruled out for this crash. The argument that killed the native hypotheses in #264 ("a native realloc bug does not produce repeating managed frames") depends on the repeating managed frames, and this dump has no managed frames at all.
Needed to progress
DISPLAYXR_PROV_EXTERNAL_WINDOW=1? That isolates the docked weave-to-texture + GameView glue path.Preferences > Analytics, or-disable-assembly-updater-style startup flags)? If disabling analytics removes the crash, that localises it cleanly.Related: #264 (main-thread stack overflow, the same dump batch).