fix(desktop): recover Windows GPU sandbox 0x80000003 startup crashes (#38216) - #66803
Closed
HexLab98 wants to merge 2 commits into
Closed
fix(desktop): recover Windows GPU sandbox 0x80000003 startup crashes (#38216)#66803HexLab98 wants to merge 2 commits into
HexLab98 wants to merge 2 commits into
Conversation
HexLab98
force-pushed
the
fix/38216-windows-desktop-sandbox-crash
branch
from
July 18, 2026 07:48
a85b161 to
093da63
Compare
Grant ALL APPLICATION PACKAGES RX on the unpacked app and stick a boot marker so fatal Chromium sandbox deaths relaunch with --no-sandbox (NousResearch#38216).
HexLab98
force-pushed
the
fix/38216-windows-desktop-sandbox-crash
branch
from
July 18, 2026 07:48
093da63 to
8896937
Compare
alt-glitch
added
type/bug
Collaborator
teknium1
added a commit
that referenced
this pull request
Jul 18, 2026
…sandbox loss Follow-up to the salvaged #66803 (@HexLab98): - Two-strike boot marker: a single mid-boot abort (task-manager kill, power loss) no longer disables the sandbox — only a second consecutive abort, or a signature-confirmed GPU/renderer STATUS_BREAKPOINT death, engages --no-sandbox. - Version-scoped stickiness: the fallback marker records the app version and re-probes the sandbox once after an update (new Electron or installer ACL repair may have fixed the host) instead of degrading forever. A failed re-probe returns straight to fallback. - Launch-time icacls repair now runs only when the marker shows a prior aborted boot (icacls /T recurses the whole install tree — healthy launches skip it; the installer grants the ACE at install time), and targets the install dir only. The userData grant is dropped: granting S-1-15-2-2 RX on userData would expose Hermes sessions/config to every AppContainer app on the machine. - Renderer crash-loop recovery (same class as #56726, credit @Sahil-SS9 in PR #57414): a Windows renderer crash loop bearing the breakpoint exit code gets the same one-shot --no-sandbox relaunch instead of a dead window; unrelated crash loops keep the sandbox. - Manual --no-sandbox launches are honored but never made sticky. Tests: 15/15 windows-sandbox-fallback vitest; full desktop electron suite 432 passed / 1 skipped.
Contributor
|
Merged via PR #66842 (#66842), rebase-merged so both of your commits landed on main with your authorship preserved in git log — thanks for the thorough work here, the injectable helper-module design and the test coverage made this a clean salvage. On top of your base we added a hardening commit addressing review findings:
Fixes #38216. Closing this PR in favor of the merged salvage. Thanks again! |
1 task
randlee
pushed a commit
to randlee/hermes-agent
that referenced
this pull request
Aug 11, 2026
…sandbox loss Follow-up to the salvaged NousResearch#66803 (@HexLab98): - Two-strike boot marker: a single mid-boot abort (task-manager kill, power loss) no longer disables the sandbox — only a second consecutive abort, or a signature-confirmed GPU/renderer STATUS_BREAKPOINT death, engages --no-sandbox. - Version-scoped stickiness: the fallback marker records the app version and re-probes the sandbox once after an update (new Electron or installer ACL repair may have fixed the host) instead of degrading forever. A failed re-probe returns straight to fallback. - Launch-time icacls repair now runs only when the marker shows a prior aborted boot (icacls /T recurses the whole install tree — healthy launches skip it; the installer grants the ACE at install time), and targets the install dir only. The userData grant is dropped: granting S-1-15-2-2 RX on userData would expose Hermes sessions/config to every AppContainer app on the machine. - Renderer crash-loop recovery (same class as NousResearch#56726, credit @Sahil-SS9 in PR NousResearch#57414): a Windows renderer crash loop bearing the breakpoint exit code gets the same one-shot --no-sandbox relaunch instead of a dead window; unrelated crash loops keep the sandbox. - Manual --no-sandbox launches are honored but never made sticky. Tests: 15/15 windows-sandbox-fallback vitest; full desktop electron suite 432 passed / 1 skipped.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
0x80000003/ exit-2147483645("GPU process isn't usable. Goodbye.").S-1-15-2-2(ALL APPLICATION PACKAGES) RX on the unpacked app dir at install time and on launch ([Bug] Electron apps crash with exit_code=-2147483645 (GPU process sandbox crash) when zombie SIDs exist in DACL electron/electron#51761 class of ACL failures).--no-sandboxrelaunch when a prior launch aborted mid-boot or a GPU child dies with the breakpoint signature — covers Start Menu / shortcut launches that never go throughhermes desktop.Test plan
npx vitest run electron/windows-sandbox-fallback.test.ts(10/10)--no-sandboxwhen the boot marker clears took.hermes updateand confirmicaclsAppContainer grant is best-effort (install still succeeds if ACL grant fails).