We run BootTest as part of our build pipeline, pretty standard CI/CD stuff, and over the months we have had a fairly high number of intermittent crashes in BootTest when it is shutting down that all seem to point to race conditions related to memory and background threads/async tasks, many have been in core rendering code or in EOS, though not all. Reasons I suspect they are a good old fashioned multithreaded race condition problem:
They do not repro consistently on the same CL on the same machine.
Any change in the attempt to repro may cause them to not repro at all (or at least at a low enough rate they are not reproduced before we run out of patience/time to investigate)
Often disappear for stretches of time (sometimes days, sometimes weeks) with no action actually taken to address them, then they start again after check ins completely unrelated to where the crashes are occurring
We often run BootTest as part of several builds, like Functional Tests, and those will all run to completion as normal, meaning that the crashes seem to be directly tied to a quick start up/shutdown situation
Is this a known issue in 5.6 or with specific features? Are there safe guards we should be using when running BootTest to protect against these?
Can you share the full command that you are using? The stack you shared in during the editor initialization and the test should not have started at that point.
The BootTest passes if I run that command on a local project. Can you share the log for the BootTest? The output from Gauntley will contain the path to the log in the test report.
Thanks for uploading the logs! Can you add a tick or a few ticks to this test? Seems like the OSS is initialized and shut down on the very same tick.
[2026.04.13-14.18.48:961][303]LogOnline: OSS: Created online subsystem instance for: EOS
[2026.04.13-14.18.48:961][303]LogSonar: Deinitializing Subsystem
I’m curious to see if we add a very small delay, if the behavior changes.
Can you also upload a dump file, with your executable and symbols? I’ll have a look at the dump on my end to see if I can spot the issue. Logs that go with the dump will also be helpful.
Sorry for the double-message here. Martin messaged me, pointing out that it was our Gauntlet BootTest that was failing. Looking at the logs, the request to exit happens much before the EOS OSS, and EOS SDK are initialized:
[2026.04.13-14.18.48:889][302]LogWindows: FPlatformMisc::RequestExitWithStatus(0, 0, <NoCallSiteInfo>)
[2026.04.13-14.18.48:914][303]LogEOSSDK: LogEOS: [Boot] EOSSDK Version 1.18.1.2-47370208 booting at 2026-04-13T14:18:48.914Z using C
I’m going to try and reproduce this in a minimal project.
I can’t reproduce this in a minimal project. Can you answer the following questions:
I noticed in your logs it seems like the default OSS is NULL, not EOS. Is that expected?
Are you calling OnlineSubsystem::Get(FName(“EOS”)) or Online::GetSubsystem(World, FName(“EOS”)) anywhere in your code?
Can you put a breakpoint in FOnlineSubsystemEOS::Init and capture the callstack during this test? Since EOS is never initialized during gameplay in this BootTest run, that breakpoint will only hit the bad path and the stack will identify the caller directly.
Can you rerun the BootTest with -LogCmds=“LogOnline VeryVerbose, LogEOSShared VeryVerbose” and send the full log?
Some of this is stuff we’ve added in our attempts to Make It Stop Crashing, like trying to disable UBA shader compiles and stuff.. So some of this is probably cruft that could be removed and we’d still be able to repro it, I’ll try to get a clean, minimal version for you.
D:\BuildAgent\work\c5e5406cf9a48cb9\UE\Engine\Binaries\ThirdParty\DotNet\8.0.300\win-x64\dotnet.exe "D:\BuildAgent\work\c5e5406cf9a48cb9\UE\Engine\Binaries\DotNET\AutomationTool\AutomationTool.dll" -p4 -nosubmit -NoCompile RunUnreal -project=Subnautica2 -build=Editor -test="UE.BootTest" -test="UE.EditorAutomation(RunTest=Project.Functional Tests)" -build=editor -maxduration=3600 -unattended -verbose -ResumeOnCriticalFailure -ClientArgs=-NoUbaShaderCompile -branch="//Project/SN2-Main-UE" -changelist="99360" -EditorArgs="-LogCmds=\"LogAudioMixer Fatal, LogD3D12RHI Fatal\" -NoSound" -ClientArgs="-LogCmds=\"LogAudioMixer Fatal, LogD3D12RHI Fatal\" -NoSound"To be clear, running these two tests together, the BootTest will crash out, and the Functional Tests will run fine (barring any actual functional test failures), and this is like 100% repro behavior in this case.
Yeah, I see it immediately flagged as no longer available.. Maybe because it is a .log? Trying .txt.. I can definitely see it attached as I write this [Image Removed]