Detect engine archive failures after spawn: 500 ms window and unused [ggc] stderr sentinel

[bobtista]

Problem

The engine already reports archive failures, and GenHub ignores them.

Verified on bobtista/GeneralsGameCode at bobtista/topic/trunk:

• A root holding no archives aborts during initialisation with exit 1 and a ReleaseCrashInfo.txt.
• An unmountable archive additionally writes to stderr:
  • [ggc] archive identifier mismatch: <file> — StdBIGFileSystem.cpp:203
  • [ggc] ARCHIVE MOUNT FAILED, contents unavailable this run: <file> — StdBIGFileSystem.cpp:357

Neither reaches the main loop. GenHub does not use either signal.

Two concrete gaps:

1. The immediate-exit window is 500 ms.

ProcessConstants.LauncherDetectionDelayMs = 500

GameProcessManager waits 500 ms, then reports "exited immediately with code {ExitCode}" with captured stderr. An initialisation abort landing inside that window is caught and reported well. One landing outside it is reported as a successful launch, and the process then dies unobserved. Whether the engine beats 500 ms on a cold start, a slow disk, or under emulation is unmeasured.

2. Nothing branches on the stderr sentinel.

The [ggc] lines are captured by the stderr work in #332 and surfaced verbatim when the exit is caught, but they are never matched. A launch that mounted nothing is indistinguishable to GenHub from any other non-zero exit, so the user gets a generic failure rather than "this archive could not be mounted".

Why this was missed

Both #315 and #332 were written on the belief that the engine reported nothing observable, so no post-spawn detection was attempted. That belief was inherited from planning notes and never checked against the engine, which is public. It is false, and the corrected reasoning is recorded in the ValidateRetailArchiveRoots remarks.

Proposed work

• Measure how long an initialisation abort actually takes, and size the detection window from that rather than the current 500 ms guess. Consider waiting for exit-or-settle instead of a fixed delay.
• Match the [ggc] sentinels in captured stderr and surface a specific message naming the archive.
• Treat the sentinel as advisory, not required: it is fork-only (StdBIGFileSystem on bobtista/topic/trunk; absent upstream on every platform, including Win32BIGFileSystem — see the correction comment below). Absence of the sentinel must not be read as success.

Windows caveat

ReleaseCrash shows a system-modal dialog before _exit(1), so on Windows a host-launched child blocks instead of exiting. No detection window of any length helps there — GenHub sees a live process indefinitely. That is engine-side work and should not be designed around here beyond not assuming a prompt exit.

Acceptance criteria

• An initialisation abort is reported as a failed launch regardless of how long it takes, not only within a fixed window.
• A mount failure produces a message naming the archive, not a generic non-zero exit.
• Behaviour is unchanged where the sentinel is absent.

Related

• Validate retail archive roots before launch #315 — pre-launch validation, complementary rather than a substitute
• feat(launching): launch the native BGFX client against retail archives #332 — stderr capture that already collects these lines
• Zero Hour can still launch with no base Generals content when no Generals root is declared #333 — the missing-base-content case, which no post-spawn signal covers yet

[coderabbitai]

🔗 Related PRs

#328 - feat(platform): make paths, manifests, and Unix workspaces platform-aware [merged]
#329 - feat(macos): add native host, installation detection, and CI [merged]
#332 - feat(launching): launch the native BGFX client against retail archives [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Capture stderr for launched processes and replace the fixed 100 ms snapshot with a 500 ms exit-or-settle race so early aborts are caught immediately, with the window promoted to ProcessConstants.LauncherDetectionDelayMs.
• Add a single, testable helper that matches the engine's advisory [ggc] archive sentinels in captured stderr and produces an archive-naming message, falling back to the existing exit-code table when absent so behaviour is unchanged without a sentinel.
• Enrich the existing ProcessExited event with exit code and stderr, and have the UI surface abnormal post-window exits so an initialisation abort is reported as a failed launch regardless of when it occurs.
• Explicitly honour the Windows ReleaseCrash modal-dialog caveat by not assuming a prompt exit and treating the sentinel as advisory-only, keeping ValidateRetailArchiveRoots/Validate retail archive roots before launch #315 pre-launch validation out of scope.

Design Choices

Design Choice 1: Is the "`#332` stderr capture" prerequisite already merged, or must this ticket provide it?

Options Considered:

1. Assume #332 lands independently and plan only sentinel matching + exit-or-settle, leaving stderr capture untouched.
2. Include a minimal stderr-capture implementation in this ticket so the acceptance criteria (which require naming the archive from stderr) are independently satisfiable.

Chosen Option: 2

Rationale: AC2 cannot be met without captured stderr and it does not exist today, so a minimal capture is included here; if #332 lands first, that portion of the plan is simply already satisfied and can be reconciled rather than duplicated. The ticket describes the [ggc] lines as "captured by the stderr work in #332", but the current codebase has no stderr redirection or buffering for launched game processes.

Design Choice 2: How should a failure that lands after the detection window be surfaced (AC1 "regardless of how long it takes")?

Options Considered:

1. Extend the existing ProcessExited event with exit code + captured stderr and have the UI/facade surface a failure notification when a tracked process exits abnormally.
2. Introduce a launch-status enum on GameLaunchInfo and an update-in-place API on ILaunchRegistry, then have consumers re-evaluate status.

Chosen Option: 1

Rationale: It reuses the already-wired ProcessExited → OnProcessExited path with the smallest surface area, satisfying AC1 without reworking the registry's success/failure model. The launch is already reported as success once the process survives the window, so a later failing exit must be corrected/surfaced asynchronously.

Design Choice 3: Authoring the `ValidateRetailArchiveRoots` remarks referenced under "Why this was missed".

Options Considered:

1. Author the method and its remarks as part of this ticket.
2. Treat it as out of scope (owned by #315, described as "complementary rather than a substitute") and only reference the corrected reasoning.

Chosen Option: 2

Rationale: This ticket is scoped to post-spawn detection; pre-launch archive-root validation is explicitly the domain of #315 and would be scope creep here. ValidateRetailArchiveRoots (and the #315 pre-launch validation it belongs to) does not exist in the tree.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Capture stderr and replace the fixed window with exit-or-settle detection

This phase makes the post-spawn detection robust and gives us the raw signal (stderr text + exit code) needed for sentinel matching. It replaces the blind fixed delay with a race between process exit and a settle timeout, captures stderr for the lifetime of tracked processes, and promotes the detection window to a shared, named constant.

Task 1: Promote and rename the detection window constant

Establish the 500 ms window as a shared, well-named constant per the ticket's ProcessConstants.LauncherDetectionDelayMs reference.

• Add a LauncherDetectionDelayMs = 500 constant to GenHub/GenHub.Core/Constants/ProcessConstants.cs, following the file's existing grouped public const int convention (add a // Timing section banner).
• Update GameProcessManager.cs to consume this constant in place of the private ProcessStartDelayMs = 100, removing the old private const.
• Treat the 500 ms value as advisory only; document in a code comment that robustness comes from exit-or-settle plus post-settle monitoring (Phase 3), not from the exact window size, and that the value should be revisited once an initialisation-abort timing measurement is available.

Task 2: Capture stderr on launched processes

Provide the raw stderr signal the sentinel matcher and failure messages require.

• In GameProcessManager.StartProcessAsync, set RedirectStandardError = true on the ProcessStartInfo (UseShellExecute = false is already set).
• Attach an ErrorDataReceived handler and call BeginErrorReadLine() after start, accumulating lines into a per-process StringBuilder buffer stored in a new ConcurrentDictionary<int, StringBuilder> keyed by PID (parallel to the existing _managedProcesses).
• Ensure the buffer is retained for processes that survive the window (so it is available at later exit) and cleaned up alongside existing process cleanup to avoid leaks.
• Keep this behaviour transparent to callers; do not add a config toggle unless required — always-on capture matches the ticket intent.

Task 3: Replace fixed-delay snapshot with exit-or-settle detection

React immediately if the process dies early, and treat survival of the window as a provisional success.

• In GameProcessManager.StartProcessAsync, replace the Task.Delay + single HasExited check with a race (e.g. Task.WhenAny of process.WaitForExitAsync(token) and a Task.Delay(LauncherDetectionDelayMs, token)), so an early exit is caught the moment it happens rather than after the full window.
• On early exit within the window: read the captured stderr buffer and exit code, then build the failure result (message construction handled in Phase 2) and return OperationResult<GameProcessInfo>.CreateFailure(...) as today.
• On survival of the window: proceed to the existing "track process + return success" path, leaving stderr capture running for later exit evaluation.
• Preserve the existing special cases (batch-file skip, exit-code-0 launcher-spawns-game heuristic via FindSpawnedGameProcess) and the WaitForExit/timeout behaviour; only the detection mechanism changes, and do not assume a prompt exit (honour the Windows modal-dialog caveat — a live-forever process simply falls through to provisional success, as it does today).

🤖 Prompt for AI agents

Implement robust post-spawn process detection with stderr capture in
`GameProcessManager`, replacing the fixed-delay snapshot with an exit-or-settle
race.

- Add a `LauncherDetectionDelayMs = 500` constant to
`GenHub/GenHub.Core/Constants/ProcessConstants.cs`, following the existing
grouped `public const int` convention with a `// Timing` section banner. Update
`GameProcessManager.cs` to consume this constant instead of the private
`ProcessStartDelayMs = 100`, and remove the old private const. Add a code
comment documenting that the 500 ms value is advisory only — robustness comes
from exit-or-settle plus post-settle monitoring (Phase 3), not the exact window
size, and it should be revisited once initialisation-abort timing data is
available.

- In `GameProcessManager.StartProcessAsync`, set `RedirectStandardError = true`
on the `ProcessStartInfo` (`UseShellExecute = false` already set). Attach an
`ErrorDataReceived` handler and call `BeginErrorReadLine()` after start,
accumulating lines into a per-process `StringBuilder` buffer stored in a new
`ConcurrentDictionary<int, StringBuilder>` keyed by PID, parallel to
`_managedProcesses`. Retain the buffer for processes that survive the window so
it's available at later exit, and clean it up alongside existing process cleanup
to avoid leaks. Keep capture always-on and transparent to callers.

- Replace the `Task.Delay` + single `HasExited` check with a race (e.g.
`Task.WhenAny` of `process.WaitForExitAsync(token)` and
`Task.Delay(LauncherDetectionDelayMs, token)`) so an early exit is caught
immediately. On early exit within the window, read the captured stderr buffer
and exit code and build a failure result via
`OperationResult<GameProcessInfo>.CreateFailure(...)` (message construction is
handled in Phase 2). On survival of the window, proceed to the existing
track-process/return-success path, leaving stderr capture running. Preserve
existing special cases (batch-file skip, exit-code-0 launcher-spawns-game
heuristic via `FindSpawnedGameProcess`) and the `WaitForExit`/timeout behaviour
— only the detection mechanism changes. Do not assume a prompt exit; honour the
Windows modal-dialog caveat by letting a live-forever process fall through to
provisional success as it does today.

Phase 2: Match [ggc] sentinels and produce archive-specific messages

This phase turns captured stderr into a specific, user-meaningful failure message when the engine's archive sentinels are present, while keeping the generic exit-code message as the fallback. The sentinel is strictly advisory.

Task 1: Define sentinel constants and a stderr classification helper

Centralise the sentinel strings and the logic that maps stderr+exit code to a message.

• Add the sentinel literals ([ggc], archive identifier mismatch, ARCHIVE MOUNT FAILED) as constants — either a new grouped section in ProcessConstants.cs or a small dedicated constants type under GenHub.Core/Constants/ — with a comment noting they originate from the engine's StdBIGFileSystem.cpp and are Windows-absent until the Win32 twin gains parity.
• Add a small, testable helper (a private method or a static internal class within GenHub/GenHub/Features/GameProfiles/Infrastructure/) that scans captured stderr for the sentinels, extracts the referenced archive filename from the matched line, and returns a specific message naming that archive (e.g. "Archive could not be mounted: <file>").
• When no sentinel matches, the helper returns null/empty so callers fall back to the existing exit-code table; absence of a sentinel must never be interpreted as success.

Task 2: Fold sentinel/stderr detail into the immediate-exit failure message

Ensure the early-exit path surfaces the specific archive message when available.

• In GameProcessManager.StartProcessAsync's early-exit branch, invoke the Phase 2.1 helper first; if it yields an archive-specific message, use it for both the _logger.LogWarning line and the OperationResult<GameProcessInfo>.CreateFailure(...) message.
• Otherwise retain the existing exit-code→message mapping (STATUS_* table / "Unknown error code") as the fallback, so behaviour is unchanged where the sentinel is absent.
• Optionally include the captured stderr text (truncated/summarised) in the failure detail so downstream logging/UI has context; thread it through the existing error-string mechanism rather than mutating the immutable result base classes.

🤖 Prompt for AI agents

Implement sentinel-based classification of captured stderr to produce
archive-specific failure messages, falling back to the existing exit-code table
when no sentinel is present.

- Define the sentinel literals (`[ggc]`, `archive identifier mismatch`, `ARCHIVE
MOUNT FAILED`) as constants, either as a new grouped section in
`ProcessConstants.cs` or a small dedicated constants type under
`GenHub.Core/Constants/`. Add a comment noting they originate from the engine's
`StdBIGFileSystem.cpp` and are absent on Windows until the Win32 twin gains
parity.

- Implement a small, testable helper (a private method or static internal class
within `GenHub/GenHub/Features/GameProfiles/Infrastructure/`) that scans
captured stderr for the sentinels, extracts the referenced archive filename from
the matched line, and returns a specific message naming that archive (e.g.
"Archive could not be mounted: `<file>`"). When no sentinel matches, the helper
must return null/empty so callers fall back to the existing exit-code table —
absence of a sentinel must never be interpreted as success.

- In `GameProcessManager.StartProcessAsync`'s early-exit branch, invoke this
helper first. If it yields an archive-specific message, use it for both the
`_logger.LogWarning` call and the
`OperationResult<GameProcessInfo>.CreateFailure(...)` message. Otherwise retain
the existing exit-code→message mapping (`STATUS_*` table / "Unknown error code")
as the fallback. Optionally include the captured stderr text
(truncated/summarised) in the failure detail for downstream logging/UI context,
threading it through the existing error-string mechanism without mutating the
immutable result base classes.

Phase 3: Surface failures that land after the detection window

This phase satisfies AC1 for aborts that occur after the process has been reported as a successful launch, by enriching the exit event and having the UI/facade react to abnormal exits instead of silently reverting to idle.

Task 1: Enrich the process-exit event with exit code and captured stderr

Give consumers enough information to classify a post-spawn exit as a failure.

• Extend GenHub/GenHub.Core/Models/Events/GameProcessExitedEventArgs.cs with a captured-stderr field (and ensure ExitCode is reliably populated) so exit-time diagnostics are available.
• Update GameProcessManager.OnProcessExited to read the per-PID stderr buffer (from Task 1.2), populate the enriched event args, and then clean up the buffer entry.
• Reuse the Phase 2.1 helper here so the event can carry a ready-made archive-specific message when a sentinel is present, keeping classification logic in one place.

Task 2: Report abnormal post-spawn exits to the user

Convert a silent post-window crash into a surfaced failed launch.

• Update GenHub/GenHub/Features/GameProfiles/ViewModels/GameProfileLauncherViewModel.cs OnProcessExited so that, in addition to reverting IsProcessRunning/ProcessId, it inspects the enriched event args and — when the exit is abnormal (non-zero exit code) or a sentinel message is present — surfaces an error via INotificationService.ShowError(...) (using an appropriate NotificationDurations value) and sets ErrorMessage/StatusMessage.
• Prefer the sentinel-derived archive-specific message when available; otherwise present a concise non-zero-exit failure message. A clean exit (code 0) continues to revert silently to idle as today.
• Keep this consistent with the existing facade/ViewModel notification conventions; avoid duplicate toasts by scoping the new notification to the post-spawn exit path only.

Task 3: Add tests for the new detection and messaging behaviour

Validate exit-or-settle, sentinel matching, and post-settle surfacing following existing patterns.

• Extend GenHub/GenHub.Tests/GenHub.Tests.Core/Features/GameProfiles/GameProcessManagerTests.cs using the established real-temp-script pattern (cross-platform .bat/.sh): a script that writes a [ggc] ARCHIVE MOUNT FAILED ... line to stderr and exits non-zero within the window (asserting the archive-specific failure message), a script that exits non-zero without any sentinel (asserting the generic fallback message), and a script that survives the window then exits abnormally (asserting the enriched ProcessExited event carries exit code + message).
• Add focused unit tests for the Phase 2.1 sentinel-classification helper (sentinel present → archive named; sentinel absent → null/fallback) since it is pure and easily testable in isolation.

🤖 Prompt for AI agents

Enrich the post-spawn exit event and surface abnormal post-window exits as
failures in the UI, then add tests covering the new detection and messaging
behaviour.

- Extend `GenHub/GenHub.Core/Models/Events/GameProcessExitedEventArgs.cs` with a
captured-stderr field and ensure `ExitCode` is reliably populated so exit-time
diagnostics are available. Update `GameProcessManager.OnProcessExited` to read
the per-PID stderr buffer (from Phase 1's capture), populate the enriched event
args, and clean up the buffer entry afterward. Reuse the Phase 2
sentinel-classification helper here so the event can carry a ready-made
archive-specific message when a sentinel is present, keeping classification
logic centralised.

- Update
`GenHub/GenHub/Features/GameProfiles/ViewModels/GameProfileLauncherViewModel.cs`
`OnProcessExited` so that, in addition to reverting
`IsProcessRunning`/`ProcessId`, it inspects the enriched event args. When the
exit is abnormal (non-zero exit code) or a sentinel message is present, surface
an error via `INotificationService.ShowError(...)` (using an appropriate
`NotificationDurations` value) and set `ErrorMessage`/`StatusMessage`. Prefer
the sentinel-derived archive-specific message when available; otherwise present
a concise non-zero-exit failure message. A clean exit (code 0) should continue
to revert silently to idle as today. Keep this consistent with existing
facade/ViewModel notification conventions and scope the new notification to the
post-spawn exit path only to avoid duplicate toasts.

- Extend
`GenHub/GenHub.Tests/GenHub.Tests.Core/Features/GameProfiles/GameProcessManagerTests.cs`
using the established real-temp-script pattern (cross-platform `.bat`/`.sh`)
with three scenarios: (1) a script writing a `[ggc] ARCHIVE MOUNT FAILED ...`
line to stderr and exiting non-zero within the window, asserting the
archive-specific failure message; (2) a script exiting non-zero without any
sentinel, asserting the generic fallback message; (3) a script that survives the
window then exits abnormally, asserting the enriched `ProcessExited` event
carries exit code and message. Also add focused unit tests for the
sentinel-classification helper covering sentinel-present (archive named) and
sentinel-absent (null/fallback) cases.

Research

The launch pipeline flows ProfileLauncherFacade (validation/UX + notifications) → GameLauncher (workspace prep + orchestration) → GameProcessManager (raw System.Diagnostics.Process control). GameProcessManager.StartProcessAsync currently does a fixed Task.Delay(ProcessStartDelayMs = 100) then a single HasExited snapshot: an early exit becomes a CreateFailure with a hard-coded Windows exit-code→message table; survival of the window is reported as success. Results flow through the immutable ResultBase/OperationResult<T>/LaunchOperationResult<T> hierarchy. Successfully tracked processes raise GameProcessManager.ProcessExited (GameProcessExitedEventArgs with ProcessId, ExitCode, ExitTime), which the UI (GameProfileLauncherViewModel.OnProcessExited) consumes only to revert to an idle state — no failure is surfaced for post-spawn crashes.

Critically, exploration confirmed that several things the ticket assumes already exist do not exist in the current tree: there is no ProcessConstants.LauncherDetectionDelayMs (only a private ProcessStartDelayMs = 100), no stderr capture at all (RedirectStandardError is never set for game launches, so the "#332" stderr work is not present), and no ValidateRetailArchiveRoots method or [ggc]/StdBIGFileSystem sentinel references anywhere.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement robust post-spawn process detection with stderr capture in
`GameProcessManager`, replacing the fixed-delay snapshot with an exit-or-settle
race.

- Add a `LauncherDetectionDelayMs = 500` constant to
`GenHub/GenHub.Core/Constants/ProcessConstants.cs`, following the existing
grouped `public const int` convention with a `// Timing` section banner. Update
`GameProcessManager.cs` to consume this constant instead of the private
`ProcessStartDelayMs = 100`, and remove the old private const. Add a code
comment documenting that the 500 ms value is advisory only — robustness comes
from exit-or-settle plus post-settle monitoring (Phase 3), not the exact window
size, and it should be revisited once initialisation-abort timing data is
available.

- In `GameProcessManager.StartProcessAsync`, set `RedirectStandardError = true`
on the `ProcessStartInfo` (`UseShellExecute = false` already set). Attach an
`ErrorDataReceived` handler and call `BeginErrorReadLine()` after start,
accumulating lines into a per-process `StringBuilder` buffer stored in a new
`ConcurrentDictionary<int, StringBuilder>` keyed by PID, parallel to
`_managedProcesses`. Retain the buffer for processes that survive the window so
it's available at later exit, and clean it up alongside existing process cleanup
to avoid leaks. Keep capture always-on and transparent to callers.

- Replace the `Task.Delay` + single `HasExited` check with a race (e.g.
`Task.WhenAny` of `process.WaitForExitAsync(token)` and
`Task.Delay(LauncherDetectionDelayMs, token)`) so an early exit is caught
immediately. On early exit within the window, read the captured stderr buffer
and exit code and build a failure result via
`OperationResult<GameProcessInfo>.CreateFailure(...)` (message construction is
handled in Phase 2). On survival of the window, proceed to the existing
track-process/return-success path, leaving stderr capture running. Preserve
existing special cases (batch-file skip, exit-code-0 launcher-spawns-game
heuristic via `FindSpawnedGameProcess`) and the `WaitForExit`/timeout behaviour
— only the detection mechanism changes. Do not assume a prompt exit; honour the
Windows modal-dialog caveat by letting a live-forever process fall through to
provisional success as it does today.
===============================================================================

Task: 2

Implement sentinel-based classification of captured stderr to produce
archive-specific failure messages, falling back to the existing exit-code table
when no sentinel is present.

- Define the sentinel literals (`[ggc]`, `archive identifier mismatch`, `ARCHIVE
MOUNT FAILED`) as constants, either as a new grouped section in
`ProcessConstants.cs` or a small dedicated constants type under
`GenHub.Core/Constants/`. Add a comment noting they originate from the engine's
`StdBIGFileSystem.cpp` and are absent on Windows until the Win32 twin gains
parity.

- Implement a small, testable helper (a private method or static internal class
within `GenHub/GenHub/Features/GameProfiles/Infrastructure/`) that scans
captured stderr for the sentinels, extracts the referenced archive filename from
the matched line, and returns a specific message naming that archive (e.g.
"Archive could not be mounted: `<file>`"). When no sentinel matches, the helper
must return null/empty so callers fall back to the existing exit-code table —
absence of a sentinel must never be interpreted as success.

- In `GameProcessManager.StartProcessAsync`'s early-exit branch, invoke this
helper first. If it yields an archive-specific message, use it for both the
`_logger.LogWarning` call and the
`OperationResult<GameProcessInfo>.CreateFailure(...)` message. Otherwise retain
the existing exit-code→message mapping (`STATUS_*` table / "Unknown error code")
as the fallback. Optionally include the captured stderr text
(truncated/summarised) in the failure detail for downstream logging/UI context,
threading it through the existing error-string mechanism without mutating the
immutable result base classes.
===============================================================================

Task: 3

Enrich the post-spawn exit event and surface abnormal post-window exits as
failures in the UI, then add tests covering the new detection and messaging
behaviour.

- Extend `GenHub/GenHub.Core/Models/Events/GameProcessExitedEventArgs.cs` with a
captured-stderr field and ensure `ExitCode` is reliably populated so exit-time
diagnostics are available. Update `GameProcessManager.OnProcessExited` to read
the per-PID stderr buffer (from Phase 1's capture), populate the enriched event
args, and clean up the buffer entry afterward. Reuse the Phase 2
sentinel-classification helper here so the event can carry a ready-made
archive-specific message when a sentinel is present, keeping classification
logic centralised.

- Update
`GenHub/GenHub/Features/GameProfiles/ViewModels/GameProfileLauncherViewModel.cs`
`OnProcessExited` so that, in addition to reverting
`IsProcessRunning`/`ProcessId`, it inspects the enriched event args. When the
exit is abnormal (non-zero exit code) or a sentinel message is present, surface
an error via `INotificationService.ShowError(...)` (using an appropriate
`NotificationDurations` value) and set `ErrorMessage`/`StatusMessage`. Prefer
the sentinel-derived archive-specific message when available; otherwise present
a concise non-zero-exit failure message. A clean exit (code 0) should continue
to revert silently to idle as today. Keep this consistent with existing
facade/ViewModel notification conventions and scope the new notification to the
post-spawn exit path only to avoid duplicate toasts.

- Extend
`GenHub/GenHub.Tests/GenHub.Tests.Core/Features/GameProfiles/GameProcessManagerTests.cs`
using the established real-temp-script pattern (cross-platform `.bat`/`.sh`)
with three scenarios: (1) a script writing a `[ggc] ARCHIVE MOUNT FAILED ...`
line to stderr and exiting non-zero within the window, asserting the
archive-specific failure message; (2) a script exiting non-zero without any
sentinel, asserting the generic fallback message; (3) a script that survives the
window then exits abnormally, asserting the enriched `ProcessExited` event
carries exit code and message. Also add focused unit tests for the
sentinel-classification helper covering sentinel-present (archive named) and
sentinel-absent (null/fallback) cases.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[bobtista]

Correction: the [ggc] sentinel is fork-only, not merely absent on Windows

This issue said the sentinel exists only in StdBIGFileSystem and so "Windows gets nothing until the Win32 twin gains parity". That understates it. Checked against TheSuperHackers/GeneralsGameCode@main:

	Upstream main	bgfx trunk
[ggc] ARCHIVE MOUNT FAILED	absent	StdBIGFileSystem.cpp:357
[ggc] archive identifier mismatch	absent	StdBIGFileSystem.cpp:203
CNC_ZH_INSTALLPATH / CNC_GENERALS_INSTALLPATH	absent	present
Win32BIGFileSystem sentinel	absent	absent

So the sentinel does not exist upstream at all, on any platform. Matching it detects mount failures only for our own client.

That does not change the work, but it changes what the code may assume:

• The matcher stays strictly advisory. Absence of the sentinel means "this build does not emit one", never "the launch was fine". That was already the plan, but for the wrong reason — the gap is any build that isn't ours, not just Windows.
• Sizing the detection window is the part that generalises. The exit-1 abort is upstream — the INI filesRead == 0 throw, the unnamed enum routing it to catch (...), and RELEASE_CRASH are all in upstream main. So measuring how long an initialisation abort takes and sizing the window from that is valid against any build, and is the more valuable half.
• The Windows caveat is also upstream: ReleaseCrash calls ::MessageBox(..., MB_SYSTEMMODAL) before _exit(1) in upstream main too, so a host-launched child hangs there regardless of fork. No window length helps.

Practical consequence: do the window work first, treat sentinel matching as an enhancement for our client, and do not let the design assume a signal that most builds will never emit.