Windows 11 (AMD GPU): app initializes then exits ~2s into startup — no window, crashpad not connected

[Blue4Life90]

What happened?

On Windows 11 Pro with an AMD GPU, the Out Loud desktop app launches, initializes substantially (displays, media manager, extension renderer contexts all come up), then exits about 2 seconds into startup — no window ever becomes visible and no tray icon appears. Because the engine doesn't stay up, the browser extension sits on "Retry Connection / Open Out Loud app" and playback does nothing.

Normal launches leave no entry in the Windows Application event log and create no %APPDATA%\Out Loud folder, so from the outside it looks like an instant crash. Enabling Chromium file logging (--enable-logging=file) shows the process actually gets deep into startup and then stops right after an AMD DirectComposition error, but that error is likely a red herring (see below). The crash reporter is "not connected," which is why nothing is written to the event log or a dump.

Environment: Windows 11 Pro x64 · AMD discrete GPU · 16 logical CPU cores · ~32 GB RAM · Windows Defender (no third-party AV; Protection History is clean — not blocked/quarantined) · reproduced from Edge with the Out Loud extension installed.

Steps to reproduce

Install Out Loud 2.1.0 (SmartScreen "Windows protected your PC" → More info → Run anyway; install completes normally).
Launch Out Loud.
Process starts, runs ~1–2 seconds, exits. No window, no tray icon.
Extension panel captures selected text but shows "Open Out Loud app / Retry Connection"; Play produces no audio (engine on 127.0.0.1:51730 never comes up).

Expected behavior:
Window opens, the local API on 127.0.0.1:51730 starts, and the browser extension connects.

Actual behavior:
App exits ~2 seconds into startup. No window or tray icon; the engine never stays up, so the extension can't connect.

App version

2.1.0

Operating system

Windows

Logs

Captured with:
"C:\Program Files\Out Loud\Out Loud.exe" --enable-logging=file --log-file=<path> --v=1

Notable lines (chronological; full ~5.4 KB log available on request):

VERBOSE1:...device_event_log_impl.cc:204 Display: EVENT screen_win.cc:1055 Displays updated, count: 2
VERBOSE1:...media_stream_manager.cc:1517 MDM::InitializeMaybeAsync() / MediaStreamManager()
VERBOSE1:...first_party_sets_handler_impl_instance.cc:270 Empty path. Failed initializing First-Party Sets database.
VERBOSE1:...configured_proxy_resolution_service.cc:1224 Failed configuring with PAC script, falling-back to manual proxy servers.
INFO:...webrtc\rtc_base\cpu_info.cc:75 Available number of cores: 16
VERBOSE1:...extensions\renderer\script_context.cc:149 Created context (WEB_PAGE)
VERBOSE1:...extensions\renderer\dispatcher.cc:577 Num tracked contexts: 2
ERROR:ui\gl\direct_composition_support.cc:612 AMD VideoProcessorGetOutputExtension failed: The parameter is incorrect. (0x80070057)
VERBOSE1:...viz\service\main\viz_main_impl.cc:86 VizNullHypothesis is disabled (not a warning)
... (display EVENT updates) ...
ERROR:third_party\crashpad\crashpad\client\crashpad_client_win.cc:867 not connected

The crashpad "not connected" line is the last event, ~2s after launch; the process is gone after it.

Before submitting

• I've searched existing issues for duplicates
• I'm on the latest release

[Blue4Life90]

Questions:
Is hardware acceleration/DirectComposition force-enabled, and would an AMD/Windows fallback (app.disableHardwareAcceleration() or a toggle) help?

Is crashpad/crashReporter meant to be enabled on Windows? Enabling it (or an early main-process log before userData exists) would make failures like this self-reporting.

Any dependency on a specific VC++ redistributable or AMD driver version for 2.1.0?

[Blue4Life90]

Root cause found + fix verified (Windows 11, AMD, Node v24).

It's not GPU or Electron. The app dies inside onnxruntime-node while creating the inference session. Reproduced with a standalone Node script, no Electron:

js

const ort = require("onnxruntime-node");
const buf = fs.readFileSync("electron/models/model_q8f16.onnx");
await ort.InferenceSession.create(buf, { executionProviders: ["cpu"] });
// → process exits 0xC0000005 (access violation), no JS error

onnxruntime-node 1.23.2 segfaults building its default (extended/all) graph optimizations for the quantized model_q8f16.onnx on Windows. It's a hard native abort, so the JS try/catch → CPU fallback in runInference never gets a chance, and crashpad is disconnected so nothing is logged (this is also why %APPDATA%\Out Loud never gets created and the event log is empty).

Fix (one line): set graphOptimizationLevel: "basic" (or "disabled") on the InferenceSession.create calls in createSessionWithFallback. Test matrix on this machine:

options | result -- | -- default | crash (0xC0000005) graphOptimizationLevel: "disabled" | ✅ graphOptimizationLevel: "basic" | ✅ mem-arena off / single-thread | crash

With "basic" applied to a source build, the app now logs ONNX session providers: cpu → Model preloaded successfully and stays running (previously it crashed right before that line, ~3 s in). Happy to open a PR.

Unrelated: npm run electron:dev also fails on Windows because of the Unix-only NODE_ENV=development electron . syntax — cross-env fixes it.

[Blue4Life90]

I've pushed the one-line fix to my fork - clean 2-line diff, GitHub confirms it's auto-mergeable:
main...Blue4Life90:fix/win-onnx-graph-optimization
Happy to open a proper PR if you enable it or add me as a contributor.

[Fedir-A]

Same thing happened after I updated. I have a NVIDIA GPU. Confused, now.

[Blue4Life90]

Reopening: I closed this prematurely when the fix worked on my machine, but the bug is still in the shipped app. Apologies for any confusion that may have caused..

Following up since this is still live in 2.1:
@Fedir-A hit the same startup crash on NVIDIA after updating ([comment above (https://github.com//issues/36#issuecomment-5021583803)), which confirms it's not AMD or machine-specific. It's the same crash described in the root cause above.

It's a quick 2-line fix, fully verified, sitting on my fork, and should merge cleanly against main:
main...Blue4Life90:fix/win-onnx-graph-optimization

In case the concern is performance or quality: graph optimizations only change how the math is computed. The "what" remains the same. The worst case with "basic" is differences in the last decimal places of the output samples, nothing audible. Speed-wise, generation still comfortably outpaced playback on my machine with "basic" (streaming never stalled). And if you'd rather not touch other platforms, it can be gated:
process.platform === "win32" ? "basic" : "all" — zero change on macOS/Linux.

Since PR creation here is restricted to collaborators, do whichever is easiest for you:

1. Cherry-pick it directly - ab467934
2. Add me as a collaborator (or relax the PR setting) and I'll open the PR properly, or
3. Just apply it by hand: add graphOptimizationLevel: "basic" to both InferenceSession.create calls in electron/tts-worker.ts.

Happy to help. As it stands, Windows users are currently dead in the water on launch.

[IBAV8N]

I have the same experience using linuxmint 22 / NVIDIA GPU. The app closes several seconds after execution. Nothing on the GUI functions while the app is open for that short time.