Vanilla G-Screen Exit Crash

SummarySpace Engineers 2 v2.4.0.95 can produce a fatal shutdown assertion involving the vanilla G-screen/toolbar UI after repeated G-screen and toolbar interaction.

The important part is that this has been reproduced in a completely vanilla game session with no mods or plugins loaded.

The assertion is:

Assertion Failure: Encountered unfinished lifetime Keen.Game2.Client.UI.TerminalScreen.GScreen.GScreenViewModel with adapter type ViewModelLifetimeAdapter.; 'lifetime.Value.IsExpired' evaluated to false

Location:

VRage.Library\Threading\TaskLifetime.cs:268

The failure happens during final application shutdown in:

TaskLifetime.CheckAndEndLifetimes()

→ VRageCore.Dispose()

→ GameApp.Dispose()

→ ManualSingleton.Dispose()

→ Program.Main()

The gameplay session itself appears to shut down normally first. The assertion occurs afterward while VRage is performing final engine/core disposal.

Game VersionSpace Engineers 2:

2.4.0.95

Operating system used for reproduction:

Windows 11

Pure Vanilla ReproductionThe final reproduction was performed with:

• No mods enabled
• No Workshop mod scripts loaded
• No plugins loaded
• No custom launch arguments
• No -plugins: argument
• No third-party code involved
• Only vanilla G-screen entries and vanilla toolbar tools used

The game log confirms the process was started with an empty argument list:

Running application with arguments:

and:

Environment.CommandLine: "...SpaceEngineers2.dll"

There was no plugin or mod bootstrap in the process.

Reproduction Steps

1. Launch Space Engineers 2 normally.
2. Make sure no mods or plugins are active.
3. Load a Survival world.
4. Open the vanilla G-screen.
5. Place several normal vanilla tools/items onto toolbar slots.
6. Repeatedly open and close the G-screen.
7. Repeatedly change/select toolbar slots.
8. Continue interacting with the toolbar and G-screen for a while.
9. Exit normally using:
   Exit To Main Menu
   
10. Allow normal shutdown to continue.
11. Check the main SpaceEngineers2_*.log.

During our successful vanilla reproduction, the log recorded approximately 147 OpenTerminal requested events before shutdown.

The exact number is probably not important. Heavy/repeated G-screen and toolbar use appears to make the issue easier to reproduce.

Actual ResultThe world/session begins normal shutdown.

Example:

Info: [UI] Showing Popup Dialog: Exit To Main Menu

followed by:

GameAppComponent.ExitGame()

LOADING_BEGIN|ApplicationExit

Destructor of entity's Game Client component WorldSessionComponent started

[Session.Dispose] Begin - Scene: Client

Several seconds later, during final engine disposal:

[VRAGE_CORE]: Disposing filesystem, crash handler and definition manager.

Immediately afterward:

Assertion Failure: Encountered unfinished lifetime Keen.Game2.Client.UI.TerminalScreen.GScreen.GScreenViewModel with adapter type ViewModelLifetimeAdapter.; 'lifetime.Value.IsExpired' evaluated to false

The crash handler then treats this as a fatal FirstAssertionException and prepares a crash report.

Expected ResultAfter exiting the world/game normally, all G-screen ViewModel lifetimes should be expired/disposed before VRageCore.Dispose() checks outstanding lifetimes.

The application should shut down without a fatal assertion or crash report.

Stack TraceThe important stack from the vanilla reproduction is:

Keen.VRage.Library.Threading.TaskLifetime.CheckAndEndLifetimes(TimeSpan timeout)

Keen.VRage.Core.VRageCore.Dispose(Boolean disposing)

Keen.Game2.GameApp.Dispose(Boolean disposing)

Keen.VRage.Library.Utils.ManualSingleton<T>.Dispose()

Keen.Game2.Program.Main(String[] args)

The assertion identifies the unfinished lifetime as:

Keen.Game2.Client.UI.TerminalScreen.GScreen.GScreenViewModel

Adapter:

ViewModelLifetimeAdapter

Condition:

lifetime.Value.IsExpired == false

Source reported by the assertion:

VRage\Sources\Library\VRage.Library\Threading\TaskLifetime.cs:268

Isolation TestingThis was originally noticed while testing a Workshop mod, so we performed progressive isolation specifically to determine whether our mod was responsible.

Test 1 — Pure vanilla, normal UI use

• No plugin launch command
• No mod
• G-screen/GearForge opened repeatedly
• Normal exit

Result:

No assertion during that particular run.

This indicated the issue was not guaranteed to happen every time.

Test 2 — Plugin/bootstrap loaded, mod disabled

• Workshop launch bootstrap present
• Gameplay mod disabled
• Vanilla G-screen/GearForge exercised heavily
• Normal exit

Result:

No assertion.

This ruled out simply loading the bootstrap as a sufficient trigger.

Test 3 — Mod active, custom tool never used

• Mod enabled
• Custom tool never crafted/equipped/used
• G-screen and vanilla GearForge heavily exercised
• Approximately 105 terminal/G-screen openings
• Normal exit

Result:

No assertion.

This showed that simply having additional mod definitions present was not sufficient to reproduce the failure.

Test 4A — Custom toolbar entry heavily exercised

• Mod active
• Custom tool placed in toolbar
• Toolbar/G-screen interaction heavily exercised
• Custom gameplay/tool entity itself never actually initialized
• No welding
• No conveyor operations
• No item transfers

Result:

GScreenViewModel shutdown assertion reproduced.

At this point the toolbar/G-screen path became the main suspect.

Test 4B — Vanilla toolbar entries only, mod still activeTo determine whether the custom toolbar entry itself was required:

• Mod remained active
• Custom tool was not used
• Toolbar filled/hammered using normal vanilla tools
• G-screen repeatedly opened and closed
• Approximately 54 terminal/G-screen interactions
• Normal exit

Result:

The exact same GScreenViewModel shutdown assertion reproduced.

This showed that the custom toolbar entry itself was not necessary.

Test 5 — Completely pure vanilla toolbar stress testThis was the decisive control.

Configuration:

• No mods
• No Workshop gameplay definitions
• No bootstrap
• No plugins
• No launch arguments
• Only vanilla tools
• Vanilla G-screen/toolbar repeatedly exercised

The game log confirms:

Running application with arguments:

with nothing following it.

There were no custom mod markers or plugin markers anywhere in the main log.

Approximately 147 vanilla OpenTerminal requested events occurred during the test.

After normal Exit To Main Menu, the exact same assertion reproduced:

Encountered unfinished lifetime Keen.Game2.Client.UI.TerminalScreen.GScreen.GScreenViewModel

Result:

PURE VANILLA REPRODUCTION CONFIRMED

This establishes that the issue does not require our Workshop mod, custom tool, bootstrap, or any third-party scripting.

Important ObservationThe problem does not appear to be simply "opening the G-screen once."

Several lighter tests completed cleanly.

Repeated/heavy G-screen and toolbar interaction appears to make the problem easier to trigger.

That suggests the issue may involve something such as:

• a GScreen ViewModel lifetime occasionally not being expired,
• an old ViewModel surviving replacement,
• repeated attach/detach of the Terminal VM,
• a subscription/continuation retaining the ViewModel,
• a lifetime token not being ended on one close/replacement path,
• or a race during UI/session teardown.

Those are only observations/suspicions based on the logs; the exact internal cause is unknown.

Repeated UI Behavior Seen in LogDuring the reproduction the game repeatedly logs sequences similar to:

OpenTerminal requested

Detaching Terminal VM

Attaching Terminal VM

Interactor: ...

Interactor Comp: ... Vanilla\Characters\System\CompositeCharacterClient.def

These sequences can occur many times before the eventual shutdown assertion.

The actual assertion does not occur during one of these interactions.

It appears only later during final application disposal when TaskLifetime.CheckAndEndLifetimes() checks for remaining live objects.

Why This Looks Like a Lifetime/Teardown ProblemBy the time the assertion appears:

• gameplay has already stopped,
• the world/session disposal sequence has begun/completed,
• engine components are being destroyed,
• LibraryEngineComponent has finished destruction,
• VRage announces it is disposing the filesystem/crash handler/definition manager,
• then TaskLifetime.CheckAndEndLifetimes() discovers the still-live GScreenViewModel.

The game therefore appears to have retained a G-screen ViewModel beyond the point where its lifetime should have expired.

Severity / Player ImpactThe issue occurs during shutdown rather than normal gameplay.

Observed effects:

• fatal assertion
• crash handler activation
• crash report generation
• otherwise-normal gameplay session before exiting

We have not observed save corruption associated with this issue.

The main concern is that a normal Exit To Main Menu/application shutdown can be reported as a crash after sufficiently heavy G-screen/toolbar interaction.

Reproduction ReliabilityIt is not 100% on every run.

For example, one earlier pure-vanilla G-screen test completed normally.

A later, much heavier pure-vanilla toolbar/G-screen stress test reproduced the assertion.

This may therefore be:

• interaction-count dependent,
• timing dependent,
• or a lifetime race that becomes more likely with repeated G-screen ViewModel creation/replacement.

The pure-vanilla stress reproduction is currently the strongest reproduction method we found.

Useful Search StringsThese strings should make the relevant sections easy to locate in the attached log:

OpenTerminal requested

Detaching Terminal VM

Attaching Terminal VM

Exit To Main Menu

GameAppComponent.ExitGame()

LOADING_BEGIN|ApplicationExit

GScreenViewModel

TaskLifetime.CheckAndEndLifetimes

lifetime.Value.IsExpired

FirstAssertionException

Attached Evidence RecommendedThe most useful file to inspect is the main pure-vanilla reproduction log:

SpaceEngineers2_260829_182546_700_5004.log

This is the decisive reproduction because it contains:

• no custom launch arguments,
• no plugins,
• no mod runtime,
• vanilla toolbar/G-screen interaction,
• normal Exit To Main Menu,
• and the final GScreenViewModel unfinished-lifetime assertion.

The associated Mission, Render12, and Stats logs are also available if useful.

Final FindingThe bug can be reproduced on Space Engineers 2 v2.4.0.95 in a completely vanilla session by heavily exercising the vanilla G-screen/toolbar and then exiting normally.

The final failure is:

Keen.Game2.Client.UI.TerminalScreen.GScreen.GScreenViewModel

remaining alive when:

TaskLifetime.CheckAndEndLifetimes()

runs during:

VRageCore.Dispose().

Hopefully the reproduction and isolation data above helps narrow down which GScreen ViewModel close/replacement path is failing to terminate its lifetime.