Windows 26.10.3: UI frozen ~35 s at startup, then recurring ~30 s main-thread stalls that drop the FLEX-6600 connection (26.10.2 works) #6584

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

After updating from 26.10.2 to 26.10.3 on Windows, AetherSDR effectively won't launch. The window doesn't become usable for ~35–41 s, and after the radio connects the UI freezes again for ~30 s at a time. The FLEX-6600 drops the connection during those freezes. It reproduced on every launch today (7 launches). I have rolled back to 26.10.2, which works normally on the same machine.

Log evidence (aethersdr-20261018-182405.log)

[18:24:07.498] WRN qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed
[18:24:42.805] INF aether.devices: Ulanzi Dial: on; a connected dial is used when detected
[18:24:43.715] WRN aether.propforecast: fetch failed: "TLS initialization failed"
[18:24:43.835] WRN default: MainThreadWatchdog: event loop stalled ~38205 ms
[18:25:14.211] WRN default: MainThreadWatchdog: event loop stalled ~30375 ms
[18:25:14.213] WRN aether.firmware: FlexBackend: published SmartSDR releases unknown: "Cannot reach FlexRadio: TLS initialization failed"
[18:25:29.124] WRN aether.audio: AudioEngine: no audio data received for 15002 ms, restarting RX (#1411)
[18:25:31.021] WRN aether.connection: RadioConnection: socket error: "The remote host closed the connection"
[18:25:51.150] WRN default: MainThreadWatchdog: event loop stalled ~35562 ms
[18:26:21.784] WRN default: MainThreadWatchdog: event loop stalled ~30410 ms
[18:26:21.785] INF aether.discovery: HL2 discovery: no Hermes-Lite 2 answered 3 sweeps on 3 interfaces

The log has a ~35 s gap with no output right after the first TLS warning (18:24:07 → 18:24:42), then four stalls of 30–38 s. Radio and audio problems follow each stall. I have no Hermes-Lite 2; that discovery line appears as a stall ends. I also have no Ulanzi dial; that line marks where the first stall ends.

Process Monitor capture (filtered to AetherSDR.exe, 74 s, 75k events)

• t = 0–4.9 s: normal startup activity.
• t ≈ 4.9–39.9 s: no file, registry, network or process events from any thread, apart from a 4 Hz stat of the log file. CPU does not peg (Task Manager). Qt thread-pool threads created at 4.5–4.9 s exit at 34.5–34.9 s, consistent with Qt's 30 s idle expiry, so no work was scheduled during the freeze.
• Just before the silence: UDP broadcasts to port 1024 on 3 adapters (4.60–4.70 s), then a TCP connect to 18.160.213.43:443 (CloudFront) at 4.80 s, ClientHello at 4.85 s and server certificate flight received. cryptnet.dll is loaded at 4.88 s, CryptnetUrlCache is read at 4.92 s, winnsi.dll loads at 4.926 s, and then nothing.
• 24 bytes arrive from the server at 34.83 s (30 s after the hello). Activity resumes at ~39.9 s.
• Second freeze: the same pattern. Connect to the same IP at 41.36 s, 24 bytes from the server at 71.38 s, resume at ~71.8 s, followed by another UDP sweep at 71.9 s. The radio TCP connection (port 4992) opens at 41.36 s, between the freezes.
• The freezes coincide with the failed propforecast fetch and the failed firmware-release check, but blocking 443 did not change the freeze, so I believe this is coincidental.

Tried / ruled out

• 26.10.2 on the same machine works normally.
• Unplugging the USB audio dongle (Corsair headset) made no difference; I have no Ulanzi dial.
• qrzero (TCI client) closed: no change.
• tls\qschannelbackend.dll is present and loads at 1.23 s.
• Outbound TCP 443 blocked for AetherSDR.exe via Windows Firewall: freeze unchanged (so the HTTPS fetches are not the cause).
• Not yet tried: fresh settings (rename AetherSDR.db), software OpenGL (AETHER_NO_GPU=1), disabling the Hyper-V/WSL virtual network adapters.

Not established: which thread is blocked and on what. I will attach a main-thread stack from the frozen process:

<paste Process Explorer thread stack or WinDbg `~0k` from a hang dump here>

My launch of 26.10.3 (18:12:40) crashed with 0xc0000005 in AetherSDR.exe, offset 0x1b4bcf4, exe timestamp 0x6ad506a6. The log ended ~80 ms after "Starting AetherSDR". This occurs after windows suggests to wait or close the app.

Logfile.CSV

aethersdr-20261018-182405.log
aethersdr-20261018-182907.log
aethersdr-20261018-182930.log
aethersdr-20261018-183051.log
aethersdr-20261018-183323.log
aethersdr-20261018-183534.log
aethersdr-20261018-183824.log
aethersdr-20261018-184618.log
aethersdr-20261018-181240.log
aethersdr-20261018-181320.log
aethersdr-20261018-181436.log
aethersdr-20261018-181700.log
aethersdr-20261018-181820.log
aethersdr-20261018-181952.log

What did you expect?

The main window should appear within a couple of seconds. The UI should stay responsive, with network fetches (propagation forecast, firmware check) never blocking the UI thread. The radio connection should not be dropped for missed keepalives, as it is on 26.10.2.

Steps to reproduce

1. Windows x64, FLEX-6600 on the same LAN, with 26.10.2 working.
2. Install AetherSDR 26.10.3 (Windows installer) over it. Downloaded from: <release URL>, SHA256 <hash>.
3. Launch AetherSDR.exe. The window is not usable for ~35–41 s.
4. After the radio auto-connects, the UI freezes for another ~30 s. The radio closes the connection ("The remote host closed the connection") and audio restarts (Perdida de audio #1411).
5. Further 30 s freezes follow. Reinstalling 26.10.2 restores normal behaviour.

AetherSDR version

26.10.3

Radio model & firmware

FLEX-6600, firmware 4.2.18.41174

Operating system

Windows

OS version and hardware

Win 11 25h2