Windows: app hangs on launch unless started with --no-sandbox

[Pelotrio]

Summary

On Windows 10, T3 Code v0.0.13 hangs on launch unless started with --no-sandbox.

Environment

• OS: Windows 10 22H2 (19045.7058)
• GPU: NVIDIA GeForce RTX 4070 Ti
• Driver: 32.0.15.9571
• T3 Code: v0.0.13
• Electron: 40.6.0 (Chromium 144.0.7559.177)

Behavior

1. Normal launch:

   • GPU subprocess crashes with exit_code=-2147483645 (STATUS_BREAKPOINT)
   • App exits with GPU process isn't usable. Goodbye.

2. With --in-process-gpu:

   • App process stays alive
   • Main window is created but remains hidden / white
   • ready-to-show never fires
   • UI never becomes usable

3. With --no-sandbox:

   • App launches and works normally

What was ruled out

• Defender exclusion for install directory: no effect
• Defender protection history: empty
• NVIDIA overlay injection: disabling overlay stopped nvspcap64.dll injection into T3 Code, but the hang persisted
• No third-party DLLs present in the renderer process at time of hang (confirmed via Process.Modules)
• Various Chromium flags (--disable-features=TextServicesFramework,CalculateNativeWinOcclusion, --disable-renderer-accessibility, --disable-direct-write, --use-gl=swiftshader): no effect
• No relevant AppLocker / CodeIntegrity / Exploit Protection findings

Likely cause

There is strong evidence of a Windows-specific sandbox interaction in the renderer path.

A minidump of the hung renderer (captured ~5 minutes after launch) shows one thread blocked in the Windows UI/message-wait path:

win32u!NtUserMsgWaitForMultipleObjectsEx+0x14
user32!RealMsgWaitForMultipleObjectsEx+0x1e
T3_Code__Alpha_!<no symbols, offset from nearest export>
...
T3_Code__Alpha_!GetHandleVerifier+0x5f77
kernel32!BaseThreadInitThunk+0x14

All other renderer threads use Win32k-safe waits (NtWaitForSingleObject, NtRemoveIoCompletion, NtWaitForWorkViaWorkerFactory). This is the only thread calling into win32u.dll.

Windows Security-Mitigations kernel event log (Event ID 10) also confirms the Win32k lockdown is active on the renderer process, with events firing at each launch attempt.

I cannot prove the exact Electron/Chromium code path from user-space alone, but this appears to be a sandbox / Win32k-lockdown incompatibility on this machine configuration. --no-sandbox consistently avoids the issue.

Workaround

"T3 Code (Alpha).exe" --no-sandbox

Request

Please investigate whether this is a known Electron-on-Windows sandbox issue in the desktop build, and whether:

• it should be reported upstream to Electron, or
• T3 Code should document --no-sandbox as a temporary workaround for affected Windows users.

I can provide the full renderer stack trace (17 threads, CDB output) and minidump if useful.