Summary
Factory Desktop 0.168.0 on Windows x64 crashes its background daemon immediately on a CPU that supports AVX but not AVX2. The daemon exits with code 3. The desktop diagnostic suggests an antivirus/endpoint hook incompatibility, but the daemon stderr shows a Bun illegal-instruction crash instead.
Environment
- Factory Desktop: 0.168.0
- OS: Windows 10 22H2 (10.0.19045)
- CPU: AMD A10 PRO-7350B R6
- Detected CPU features:
sse42 avx; no_avx2
- Bundled runtime: Bun 1.3.14, Windows x64
- OS architecture: x64
Evidence
The daemon stderr repeatedly contains:
Bun v1.3.14 (0d9b296a) Windows x64
Windows v.win10_cu
CPU: sse42 avx
Features: no_avx2
panic: Illegal instruction at address 0x7FF61B83F82C
panicked during a panic. Aborting.
The desktop log reports:
[daemon] Exited unexpectedly ... code=3
It also records daemonFailureHypothesis: "av_hook_incompat", which appears to be a misleading heuristic for this case. No antivirus allowlist change was needed to reproduce or resolve the issue.
Steps to reproduce
- Install Factory Desktop 0.168.0 on a Windows x64 system without AVX2 support.
- Sign in and launch the app.
- The app starts
resources\\bin\\droid.exe daemon --droid-path ... --listen ipc.
- The daemon exits within approximately two seconds with exit code 3, and the app retries before giving up.
Expected behavior
Factory Desktop should either:
- automatically use an x64-baseline daemon build when AVX2 is unavailable, or
- detect the missing CPU feature before spawning and show a clear compatibility message.
The official Factory CLI distribution provides an x64-baseline build for older CPUs, so the Desktop app should be able to use the equivalent runtime.
Workaround and confirmation
I downloaded the official matching 0.168.0/windows/x64-baseline/droid.exe build and verified its SHA-256 checksum (56cfcd8e2668cea940d6f9f04f83f13470620c917dc5696bca4ae2245ffea22f). Replacing the bundled daemon binary with this baseline build made the same installation start successfully:
droid --version returned 0.168.0.
- The daemon remained running.
- The Desktop log reported
daemon_ipc_ready with outcome: "ok".
- Startup completed with
outcome: "healthy" and daemon_ready.
This strongly indicates an AVX2 compatibility issue in the bundled x64 runtime rather than antivirus blocking.
Request
Please ship a CPU-compatible baseline fallback in Factory Desktop (or make the Windows installer select the baseline runtime on systems without AVX2) and update the diagnostic so users are not unnecessarily directed to disable or bypass endpoint protection.
Summary
Factory Desktop 0.168.0 on Windows x64 crashes its background daemon immediately on a CPU that supports AVX but not AVX2. The daemon exits with code 3. The desktop diagnostic suggests an antivirus/endpoint hook incompatibility, but the daemon stderr shows a Bun illegal-instruction crash instead.
Environment
sse42 avx;no_avx2Evidence
The daemon stderr repeatedly contains:
The desktop log reports:
It also records
daemonFailureHypothesis: "av_hook_incompat", which appears to be a misleading heuristic for this case. No antivirus allowlist change was needed to reproduce or resolve the issue.Steps to reproduce
resources\\bin\\droid.exe daemon --droid-path ... --listen ipc.Expected behavior
Factory Desktop should either:
The official Factory CLI distribution provides an x64-baseline build for older CPUs, so the Desktop app should be able to use the equivalent runtime.
Workaround and confirmation
I downloaded the official matching
0.168.0/windows/x64-baseline/droid.exebuild and verified its SHA-256 checksum (56cfcd8e2668cea940d6f9f04f83f13470620c917dc5696bca4ae2245ffea22f). Replacing the bundled daemon binary with this baseline build made the same installation start successfully:droid --versionreturned0.168.0.daemon_ipc_readywithoutcome: "ok".outcome: "healthy"anddaemon_ready.This strongly indicates an AVX2 compatibility issue in the bundled x64 runtime rather than antivirus blocking.
Request
Please ship a CPU-compatible baseline fallback in Factory Desktop (or make the Windows installer select the baseline runtime on systems without AVX2) and update the diagnostic so users are not unnecessarily directed to disable or bypass endpoint protection.