Summary

AetherSDR v26.5.2.1 crashes deterministically (hard 0xc0000005
access violation, no warning) when a TCI client drives a tune carrier on/off
a couple of times — i.e. tune:0,true; then tune:0,false;, repeated. The
faulting path is the TransmitModel::commandReady signal being activated
from TransmitModel::stopTune() while that slot is delivered as a queued
meta-call from the TCI command path.

Environment

• AetherSDR built from v26.5.2.1 (ef2f218, Release v26.5.2.1 (#2808)),
  Windows 11, Qt 6.10.3 (MSVC), RelWithDebInfo.
• Build is a local fork but the only divergence from upstream is a cosmetic
  version-suffix patch touching only CMakeLists.txt, src/main.cpp
  (setApplicationVersion), src/gui/TitleBar.cpp (version compare).
  Nothing in the TCI / transmit path is modified — effectively stock
  upstream v26.5.2.1.
• Radio: FlexRadio, connected in AE (TCI server bound on :40001).

Reproduction (minimal, ~100%)

1. Connect the radio in AE so the TCI server is listening.
2. From any TCI client: tune_drive:5; → tune:0,true; → wait ~1.5 s →
   tune:0,false;. Repeat for a second value (e.g. tune_drive:10;).
3. AE crashes on/around the second tune-off cycle.

A tiny Python harness that triggers it every time is available (steps a
tune_drive list, keys tune:0,true;/false;, reads tx_sensors). Happy
to attach.

Evidence

Windows Error Reporting: APPCRASH, AetherSDR.exe, faulting module
Qt6Core.dll 6.10.3.0, exception 0xc0000005, fault bucket
2094585919850238496.

Symbolized faulting stack (private AE PDB) — captured twice from two
independent crashes (PID 29548 and PID 16144), frame-for-frame identical:

Qt6Core!QObject::qt_static_metacall+0x103d        ; AV: mov r14,[rcx+8], rcx=0x250
Qt6Core!QMetaObject::activate+0x84
AetherSDR!AetherSDR::TransmitModel::commandReady(const QString&)+0x2a
AetherSDR!AetherSDR::TransmitModel::stopTune()+0x29
Qt6Core!QMetaCallEvent::placeMetaCall+0x3b        ; stopTune delivered as a QUEUED meta-call
Qt6Core!QObject::event+0x187
Qt6Widgets!QApplicationPrivate::notify_helper
Qt6Widgets!QApplication::notify
Qt6Core!QCoreApplication::notifyInternal2
Qt6Core!QCoreApplicationPrivate::sendPostedEvents+0x203
Qt6Core!QEventLoop::exec  ->  AetherSDR!main

Determinism is solid: two independent runs, identical symbolized stack +
identical Windows fault bucket. Control: the second process survived 123 s
idle and died within seconds of the TCI tune — so this is the tune: path,
not environment/instability.

Analysis (evidence-bounded — not prescribing a fix)

• TransmitModel::stopTune() is only emit commandReady("transmit tune 0")
  (src/models/TransmitModel.cpp:423).
• The crash is inside Qt's QMetaObject::activate walking commandReady's
  connection list with a garbage receiver pointer (rcx=0x250).
• stopTune() is reached via a queued QMetaCallEvent (TCI command path
  marshalling onto the model thread, then the synchronous commandReady
  emit).
• commandReady is connected at src/models/RadioModel.cpp:328 to a
  this-context lambda on RadioModel.
• Consistent with a thread-affinity / connection-lifetime issue on the
  TCI → TransmitModel path (receiver/connection state invalid at emit). The
  exact mechanism is yours to pin in the threading model — flagging the
  evidence, not the patch.

Honest caveats

• Reporter runs a local fork build; divergence is 3 cosmetic files, none in
  this path — stated for transparency.
• An AV product hook (aswhook) was injected in-process. Noted for
  completeness; a frame-identical double-repro on the same code path argues a
  genuine AE concurrency/lifetime bug rather than an AV artifact.
• Not bisected against earlier versions — whether this is a v26.5.2.1
  regression or latent-and-newly-exposed is unknown, not claimed.

Offer

Two symbolized minidumps + the matching PDB + the repro harness available on
request. Can test candidate patches quickly on this setup.

73, Nigel G0JKN/W3 & Claude (AI dev partner)