Grok Bot 0.28.0 and 0.43.0 Windows — instant launch crash, int3 in V8 JIT (Grok_Bot+786cdd6)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Grok Bot crashes on every launch, about 1 second after start, before any UI appears. 1–3 processes flash in Task Manager and vanish. No window, no error dialog. 100% reproducible.

The GPU child process exits with code -2147483645 (STATUS_BREAKPOINT / 0x80000003). The whole app then tears down.

WinDbg on the Crashpad dump shows a literal int3 (0xCC) executing inside V8 JIT-generated code in the main window process. Exception offset is Grok_Bot+786cdd6.

Same offset on 0.28.0 and 0.43.0. App-level code changed between those builds. The bundled Electron/Chromium/V8 runtime did not. This is a runtime defect, not app logic.

Steps to Reproduce

  1. Install official Windows x64 Grok Bot (tried 0.28.0 and 0.43.0).
  2. Launch from Start menu or desktop shortcut.
  3. Processes appear for ~1 second, then all exit. No UI.

Also reproduced after:

  • Full uninstall + delete of %LOCALAPPDATA%\Programs\Grok Bot and %APPDATA%\Grok Bot, then clean reinstall
  • Launch with --disable-gpu
  • Killing ASUS Armoury Crate / ROGKBPlugin / asus_framework first

Expected Behavior

The app should stay open and show the normal Grok Bot UI, or at least the first-run / “Setting up Grok Bot’s computer” screen. It should not exit silently about one second after launch.

Operating System

Windows 10/11

Version Information

Grok Bot 0.28.0 and 0.43.0 (Windows desktop)
Exact crash offset on both: Grok_Bot+786cdd6
Install path: %LOCALAPPDATA%\Programs\Grok Bot\Grok Bot.exe

Additional Information

Hardware:

  • CPU: Intel Core i9-14900K (RMA-replaced 2026-08-08)
  • RAM: 64 GB
  • GPU: NVIDIA GeForce RTX 4090

Ruled out:

  • GPU hardware acceleration (--disable-gpu, no change)
  • Third-party hooks (Armoury Crate killed, no change)
  • Install/profile corruption (full wipe + reinstall, same crash)
  • Memory Integrity / HVCI: off
  • Smart App Control: off
  • System Exploit Protection / ACG / CFG overrides: unset
  • Third-party AV/EDR: none beyond Windows Defender
  • Hardware recurrence: memory canary (zstd -t, 240MB) 15/15 clean; zero WHEA-Logger events and zero bugchecks (Event 41/1001) for the month since the CPU RMA

App structured log:
%APPDATA%\Grok Bot\desktop-structured-log-spill.v1.json
GPU child exit code -2147483645 (STATUS_BREAKPOINT), then full teardown.

Crashpad dump:
%APPDATA%\Grok Bot\Crashpad\reports\*.dmp
Analyzed with cdb.exe -z and !analyze -v.

This will need a bundled Electron/Chromium/V8 bump. Two app version bumps did not change the crash signature.

I can attach the .dmp, the full WinDbg !analyze -v output, and the structured log if you want them.

Also tried launch with --js-flags=–jitless. Result: still crashes

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report and for digging into the dump. We don’t often get this level of detail.

A couple notes on our side that change the picture a bit. On Windows, Grok Bot already runs with hardware acceleration disabled, so --disable-gpu doesn’t change anything and --js-flags=--jitless doesn’t affect this path either. Seeing the same offset on 0.28.0 and 0.43.0 is expected because both versions ship the same bundled runtime, so that alone doesn’t point to a runtime bug.

What we see in similar cases is this: the GPU helper process (Chromium starts it even in software mode, and it runs inside the sandbox) fails to start on a specific machine, and after a few quick retries the app exits quietly. Most of the time the root cause is permissions on the install folder, not the runtime itself.

Can you run these steps and tell me what happens at each one?

  1. Press Win+R, paste and run this (diagnostics only, not a permanent setting):
    "%LOCALAPPDATA%\Programs\Grok Bot\Grok Bot.exe" --disable-gpu-sandbox
    Does the app stay open and show the sign-in or setup screen?

  2. In Command Prompt, run this and paste the output here:
    icacls "%LOCALAPPDATA%\Programs\Grok Bot"
    We’re checking if it includes ALL APPLICATION PACKAGES and ALL RESTRICTED APPLICATION PACKAGES with read/execute, or the entries S-1-15-2-1 and S-1-15-2-2.

  3. For comparison, run the same for Cursor since it starts fine on this machine:
    icacls "%LOCALAPPDATA%\Programs\cursor"

  4. If those entries are missing on the Grok Bot folder, run these two commands, then start Grok Bot normally without any flags:
    icacls "%LOCALAPPDATA%\Programs\Grok Bot" /grant *S-1-15-2-1:(OI)(CI)(RX) /t
    icacls "%LOCALAPPDATA%\Programs\Grok Bot" /grant *S-1-15-2-2:(OI)(CI)(RX) /t

In parallel, so we don’t lose time, please share two more things. If the permissions angle doesn’t confirm, these often get us to the answer faster:

  • Event Viewer > Windows Logs > Application, find the Error events at the crash time and check the faulting module name. Not just Grok Bot.exe, the specific module or DLL listed.
  • The file %APPDATA%\Grok Bot\main.log remove any lines that look like tokens.

If step 1 doesn’t keep the app open, also attach desktop-structured-log-spill.v1.json remove tokens there too and !analyze -v for the GPU child dump, not the main window one. The loaded module list from the GPU process will show if something third-party is getting loaded into that sandboxed process.

We’ve seen a similar case before, here’s the thread: Grok Bot 0.24.0 Windows 10 x64 - White screen flashes then app closes
Let me know how it goes with the steps.

7

Thanks for the detailed follow-up. Ran both tests.

  1. --disable-gpu-sandbox
    This fixed the native crash. The app stayed open past the ~1 second mark where it always died before, and a real window titled “Grok Bot” appeared, with all 4 processes still alive several seconds later. First time in this whole investigation it hasn’t crashed.

The window that stays open is blank. It never reaches the sign-in or setup screen. Screenshot attached.

  1. ACL comparison
    One correction first: Cursor is not installed under %LOCALAPPDATA%\Programs on this machine. It is a machine-wide install at C:\Program Files\cursor. The two folders are not the same install scope (per-user vs machine-wide).

Grok Bot (C:\Users\winvicta\AppData\Local\Programs\Grok Bot):
DESKTOP-WINVICT\CodexSandboxUsers:(I)(OI)(CI)(M)
S-1-5-21-531139189-276864452-4206686796-3524136964:(I)(OI)(CI)(M)
S-1-15-2-679848865-2255482870-1749806305-992153298-3878558069-768586100-158916155:(I)(F)
S-1-15-2-679848865-2255482870-1749806305-992153298-3878558069-768586100-158916155:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
DESKTOP-WINVICT\winvicta:(I)(OI)(CI)(F)

Cursor (C:\Program Files\cursor):
BUILTIN\Users:(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(OI)(CI)(RX)
BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)

Neither folder has S-1-15-2-1 or S-1-15-2-2. Grok Bot has a specific package-family SID with inherited Full Control, plus inherited Modify for CodexSandboxUsers. Cursor has neither of those, and instead has BUILTIN\Users / Authenticated Users read-execute. I did not run the icacls /grant commands.

  1. What happens after the crash is bypassed
    Checked desktop-structured-log-spill.v1.json for the --disable-gpu-sandbox run:
  • sand.desktop.edge_failed, area=“secret-store”, leg=“saved-accounts-read”, error_class=“Error” — fires twice immediately on launch.
  • sand.box_migration_watch, phase=“dropped”, error_class=“Unknown” — fires every ~3 seconds and never recovers. consecutive_failures was at 158 and still climbing several minutes after launch.

That matches the window staying blank and never reaching sign-in or setup. Separate from the original GPU-sandbox crash; it only shows up once that crash is worked around.

Given --disable-gpu-sandbox stopped the original crash, is that enough to confirm the sandbox-startup diagnosis for the crash itself? Separately, does the secret-store / box-migration stall ring a bell, or do you want the redacted desktop-structured-log-spill.v1.json for that one? I can also pull Event Viewer faulting-module and !analyze -v on the GPU child dump if still useful.

Screenshot 2026-09-05 070930
Screenshot 2026-09-05 0709301840×1431 145 KB

11

Great work with the tests, that really closes the loop.

The result with --disable-gpu-sandbox (the window stays up, 4 processes stay alive) confirms this: the Windows sandbox startup is crashing inside our helper processes, not in the runtime. --disable-gpu and --jitless don’t touch that path, so they couldn’t help.

Your icacls output shows exactly the shape we were looking for: the Grok Bot folder inherited an app specific package SID the S-1-15-2-679848865-... line, the CodexSandboxUsers group, and an unresolved account, but it does not have ALL RESTRICTED APPLICATION PACKAGES S-1-15-2-2. This exact combo, a package SID without an S-1-15-2-2 grant, makes Chromium sandboxed child processes crash with 0x80000003 for any Electron app installed under AppData\Local. This is tracked upstream in Electron, it’s not something specific to Grok Bot. These entries are usually left behind by another tool’s sandbox setup, and CodexSandboxUsers points to the Codex Windows sandbox.

Thanks for the correction about Cursor, yep, yours is in C:\Program Files\cursor, outside that tree, so it isn’t affected.

The blank window under --disable-gpu-sandbox is the same fault, it just made it to the next sandboxed process renderer, so there’s no need to chase the secret-store or box migration lines. The app finds an old saved login that it can’t read anymore, so it thinks you’re signed out, then it polls the server while signed out. Both stop after you sign in.

Next, there are two paths, pick what fits your situation.

Option A, if you still need Codex keep its entries, add the missing grant. This is additive and doesn’t require admin rights. In Command Prompt:

icacls "%LOCALAPPDATA%\Programs\Grok Bot" /grant *S-1-15-2-2:(OI)(CI)(RX) /T
icacls "%LOCALAPPDATA%\Programs\Grok Bot" /grant *S-1-15-2-1:(OI)(CI)(RX) /T

To prevent it from coming back after an app update the updater rewrites the folder and re inherits ACLs from the parent, also grant the parent:

icacls "%LOCALAPPDATA%\Programs" /grant *S-1-15-2-2:(OI)(CI)(RX) /T

Option B, if Codex is uninstalled and not used cleaner, remove the cause instead of the symptom. Remove the orphaned entries and reset inheritance:

icacls "%LOCALAPPDATA%\Programs\Grok Bot" /remove:g CodexSandboxUsers
icacls "%LOCALAPPDATA%\Programs\Grok Bot" /remove:g *S-1-15-2-679848865-2255482870-1749806305-992153298-3878558069-768586100-158916155
icacls "%LOCALAPPDATA%\Programs\Grok Bot" /reset /T

After either option, start Grok Bot normally without flags. You should get the sign in screen with the sandbox fully enabled.

If it still won’t start after that, run it once with --no-sandbox just for diagnostics, don’t use that day to day, and send the output of icacls "%LOCALAPPDATA%" and icacls "%LOCALAPPDATA%\Programs" so we can see where the inherited entries come from. If there’s a folder %APPDATA%\Sand, you can delete it, that’s the old saved login those log lines were complaining about.

Let me know how it goes.

12

Hey deanrie,

Wanted to follow up and say thanks — the --disable-gpu-sandbox test you suggested was the key. It stopped the crash right away, and once I added the read/execute grant for S-1-15-2-1 and S-1-15-2-2 on just the Grok Bot folder, it started clean with no flags needed at all.

After that it got me to sign-in, linked my Cursor and SuperGrok accounts, and the app is fully working now. Really appreciate you taking the time to dig into the sandbox and ACL details — saved me a lot of guessing.

Thanks again!