Skip to content

Freebuff Desktop: infinite loading screen on launch, reproducible across 0.0.73, 0.0.74, 0.0.75 (Windows) #1136

Description

@Annguyen0410

What happened

Summary

On Windows, Freebuff Desktop opens its window successfully but the UI never finishes loading — it is stuck on the loading screen indefinitely. This has reproduced identically across three consecutive releases (0.0.73, 0.0.74, 0.0.75), and another user reported the same class of failure starting at 0.0.71 (#1093, "the Freebuff shell is gone; shutting down"). I've done fairly deep isolation testing (details below) that rules out GPU, antivirus, and a broken Electron/install, and narrows the likely fault to the renderer bootstrap path (JS bundle / preload / IPC) rather than the backend.

Environment

  • OS: Windows (please run winver and fill in your exact build, e.g. Windows 11 23H2)
  • Freebuff Desktop versions affected: 0.0.73, 0.0.74, 0.0.75
  • GPU: NVIDIA RTX 2060 (driver 31.0.15.3209, 2023), Intel UHD 630 (driver 27.20.100.9664, 2021)
  • Install path: C:\Users\<user>\AppData\Local\Programs\@codebufffreebuff-desktop\

What happened

  1. Launch Freebuff.exe.
  2. The Desktop window appears normally (MainWindowHandle present, Responding = True in Task Manager).
  3. The UI shows a loading spinner that never completes — the app never becomes interactive.
  4. On some runs, the orchestrator log additionally shows:
    [shell-lifetime] the Freebuff shell is gone; shutting down
    [shutdown] graceful shutdown complete
    
    which matches the pattern reported in freebuff.exe crushed in windows #1093.

What I already verified (ruling things out)

  • Orchestrator/Bun is healthy: log shows freebuff-desktop orchestrator listening on http://127.0.0.1:<port> with no errors.
  • Backend HTTP serves the UI correctly: Invoke-WebRequest http://127.0.0.1:<port>/ returns 200 OK with valid index.html content.
  • Electron itself is not broken on this machine: a minimal standalone Electron app (BrowserWindow loading https://example.com) launches and renders fine.
  • Not a GPU issue: reproduced identically with --disable-gpu --disable-gpu-compositing --disable-gpu-sandbox --disable-gpu-rasterization.
  • Not blocked by Windows Defender: checked Microsoft-Windows-Windows Defender/Operational event log — no entries referencing Freebuff, Electron, or Bun processes.
  • Not an installation/corruption issue: resources\app.asar, resources\orchestrator\, resources\bun\, and resources\orchestrator\ui\index.html are all present and intact.
  • Not version-specific: identical symptom across 0.0.73, 0.0.74, and 0.0.75.

Where I believe the bug is

Since the backend (/) returns 200 and Electron itself works standalone, the failure looks like it's isolated to one of:

  1. The renderer's JS bundle failing to load/execute after index.html is served.
  2. preload.cjs throwing or failing silently, breaking the IPC bridge.
  3. Renderer ↔ main process IPC calls (auth/session/config) hanging indefinitely, leaving the UI stuck on its loading screen.
  4. A specific orchestrator API route (not /) that the frontend depends on during bootstrap, which may be erroring or never responding.

This matches the discussion in #1093 and the self-kill/shell-lifetime issue partially addressed (but not merged) in PR #886.

Related issues/PRs

Steps to reproduce

  1. Install Freebuff Desktop 0.0.73, 0.0.74, or 0.0.75 on Windows.
  2. Launch Freebuff.exe.
  3. Observe infinite loading screen; UI never becomes interactive.

Expected behavior

Freebuff Desktop UI loads normally after the orchestrator starts.

Suggested next diagnostic step (for maintainers or anyone reproducing)

Launch with remote debugging enabled to inspect the renderer's Console/Network tabs directly:

Freebuff.exe --remote-debugging-port=9222

then attach via chrome://inspect to check for:

  • Failed/404 JS or CSS asset requests
  • Uncaught exceptions in the renderer console
  • Pending/never-resolving network requests during bootstrap

Happy to run this and attach logs if a maintainer can point me to which endpoint(s) the frontend depends on during startup.

Where does this happen?

Desktop app

Operating system

Windows

Version

0.0.75

Model

No response

Logs or screenshots

Metadata

Metadata

Assignees

No one assigned

    Labels

    type:bugA defect in the code with a reproducible failure

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions