Using the template below will greatly help the team reproduce the issue and ease the process of fixing it. Before posting, search for an existing report. If you are not sure it’s a bug, please first report in User Support Hub.
3 tags are required - add them in the tag section next to the title above:
-
One for iteration (msfs-2024)
-
One for platform (steam)
-
One for aircraft if related (Cowansim H125 Realism Mod V9.0 and DHL AS350 B2 SOUND PACK)
FREQUENCY OF ISSUE
After one hour
REPRODUCTION STEPS
Please list clear steps you took in order to help our test team reproduce the same issue:
-
flight with mobi flight peripherals
-
spad.next peripherals
-
A physic H125 cockpit using
YOUR SETTINGS
If the issue still occurs with no mods and add-ons, please continue to report your issue. If not, please move this post to the User Support Hub.
What peripherals are you using:
[PC Only] Are you using Developer Mode or have you made any changes to it?
No
[PC, MSFS 2020 Only] Are you using DX11 or DX12?
MSFS 2024
[PC Only] What GPU (Graphics Card) do you use?
Ryzen 7 5800X
[PC Only] What other relevant PC specs can you share?
RTX MSI 5080, 48 GB RAM, 1 TB SSD.
MEDIA
MSFS 2024 — Extended SimConnect Communication Failures in a Physical H125 Cockpit: Extended Field Tests and Community Reports
Author: Gabriel Pereira Pombo — Computer Engineer; helicopter pilot and physical cockpit developer
Location: Ponta Porã, Mato Grosso do Sul, Brazil
Date: October 9, 2026
Project: SimConnect Stability Research — MSFS 2024
Status: Technical forum report, revision 1.1; Test 2 data collection ongoing
Summary for the community
I am documenting a recurring long-session communication failure affecting an MSFS 2024 helicopter cockpit with external hardware. Before the current experimental intervention, SPAD.neXt and MobiFlight could remain apparently connected while cockpit inputs stopped working at roughly the same time, often after approximately 80–120 minutes (typically around 90 minutes). The simulator itself did not necessarily crash.
After introducing a proprietary experimental intervention, two subsequent extended sessions remained operational well beyond that historical failure window. The first session has diagnostic records covering 4 h 37 min 51 s. During the second session, the operator reported more than five hours of continued operation, with further testing planned. These are promising observations, although the intervention’s causal role and underlying failure mechanism remain under investigation.
I would particularly like to hear from users of SPAD.neXt, MobiFlight, SIMiONIC, Axis and Ohs, Stream Deck integrations, or other SimConnect-based hardware bridges who have seen multiple interfaces stop responding while the simulator continues running.
- Operator and technical context
My work combines practical helicopter operating experience, including the AS350/H125 Écureuil family, with development and integration of a physical H125 cockpit. I evaluate simulator behavior from both the flight-dynamics and systems-integration perspectives. I maintain direct technical communication with contacts at CowanSim (including Joshua) and with the Realism Mod developer; this post represents my own observations and does not imply either developer endorses the conclusions.
The CowanSim H125 is a legitimately obtained aircraft package. In my assessment, the Realism Mod materially improves rotorcraft flight dynamics and handling realism. The present report is intended to identify and isolate an integration issue, not to criticize the quality of the aircraft or realism work.
- Reproduction environment
Component — Test configuration
Simulator — Microsoft Flight Simulator 2024, PC / Steam
Aircraft — CowanSim H125, v3.3 (version used in these tests)
Flight-dynamics enhancement — Realism Mod v9.0, as reported by the operator
External interfaces — SPAD.neXt and MobiFlight
Communication — SimConnect; additional aircraft-specific variable/event integration may be involved
Hardware — Custom-built physical H125 cockpit, switches, indicators and external interfaces
Operational examples — Fire Test, Horn, autopilot and other cockpit functions
Scenery — Includes photogrammetry-intensive regions
Evidence — Timestamped diagnostic records and operator-confirmed physical-control tests
Hardware specifications, exact SPAD.neXt/MobiFlight builds, bridge versions, and precise MSFS build number should be added before final publication if available.
-
Historical failure signature
-
During prolonged sessions, SPAD.neXt and MobiFlight would cease controlling/responding to the physical cockpit at approximately the same time.
-
Both applications could still appear connected, making a simple connection-status indicator insufficient to diagnose the fault.
-
The failure occurred during both helicopter flight and prolonged stationary/engine-idle simulation; it was not restricted to active maneuvering.
-
In the operator’s comparative experience, the recurring failure was not observed with the Realism Mod disabled. This is an important association but is not, by itself, proof that the mod contains the root defect.
-
The operator also reports earlier loss-of-communication experiences with SIMiONIC G1000/iPad integration. Those experiences provide historical context, not a controlled test of the same root cause.
Working hypothesis: a shared communication path or dependency becomes impaired, potentially involving SimConnect session behavior, an aircraft/mod integration path, WASM/LVAR/HVAR bridge interactions, request scheduling, or resource pressure. A simultaneous symptom across clients is suggestive, but it does not uniquely identify SimConnect itself as the failing component.
- Experimental approach and disclosure scope
The test campaign compared the previously observed failure pattern with extended sessions conducted after an internally developed, proprietary intervention was introduced. Functional validation included repeated checks of physical cockpit inputs and simulator responses. Diagnostic records were retained to support timing and process-stability observations.
Implementation details, tools, internal architecture, activation conditions, and source code are intentionally excluded from this public report. The available data demonstrate the observed operating outcomes; they do not, by themselves, establish a specific internal SimConnect failure mechanism or prove causality.
- Test 1 — documented extended session
Evidence: Privately retained timestamped diagnostic records
Window: October 8, 2026, 18:21:06–22:58:57 (local timestamp as recorded by Windows)
Elapsed: 4 h 37 min 51 s
Diagnostic observations: 6,498
Observed processes: 3,246 FlightSimulator2024.exe rows; 3,252 SPAD.neXt.exe rows
Evidence limitation: The available records do not independently capture MobiFlight process metrics; its operational state is based on physical cockpit checks reported by the operator.
Measurement — FlightSimulator2024.exe — SPAD.neXt.exe
PID throughout sampled session — 19316 — 11592
Initial working set — 6,002.0 MB — 650.5 MB
Final working set — 8,812.8 MB — 477.3 MB
Peak working set — 14,610.0 MB — 709.8 MB
Initial private memory — 4,951.3 MB — 634.6 MB
Final private memory — 17,786.6 MB — 667.7 MB
Peak private memory — 23,031.5 MB — 815.4 MB
Maximum sampled normalized CPU — 73.12% — 4.32%
Responding=False observations — 1 (22:58:22) — 0
Interpretation: Both sampled processes retained the same PID. SPAD.neXt was marked responsive throughout. One Responding=False sample for the simulator near the end is a Windows GUI responsiveness signal, not direct evidence of a SimConnect interruption. Simulator private memory increased considerably; this is worth studying but does not establish a memory leak (cache, scenery allocation and other causes are possible). No sustained 100% normalized CPU utilization was observed in the captured samples.
Functional observation reported by the operator: Physical controls, including Fire Test and Horn, continued to work beyond the historical failure interval. This observation is not independently encoded in the diagnostic records.
- Test 2 — long-duration follow-up (provisional)
A second extended test session was started around midnight between October 8 and October 9, 2026. The helicopter was initially left running on the ground, with fuel replenished, and the operator planned further active flying, autopilot engagement, and longer-duration exercise of cockpit functions.
By the morning of October 9, the operator reported more than five hours of continuous operation without the previously observed simultaneous SPAD.neXt/MobiFlight failure. Physical cockpit controls were reported responsive. The session was being extended further, potentially toward ten hours. The operator also tested the simulator’s Active Pause feature during this extended session: physical cockpit commands remained responsive after Active Pause, with no observed interruption or reconnection required. This describes continuity, not recovery after a disconnect.
This is an interim operator report. The final diagnostic record for Test 2 has not yet been analyzed. Its final duration should be confirmed before publication as a completed result.
A separate custom chronometer gauge did not display elapsed hours as expected after approximately 3 h 30 min, although its timing behavior reportedly continued. This is a distinct gauge-display/logic issue, not evidence that the SimConnect communication failed.
- Comparison against historical behavior
Scenario — Historical result — After proprietary intervention
Extended session — Failure commonly around 80–120 minutes — Test 1: 4 h 37 min 51 s without reported loss of physical controls
Simultaneous SPAD.neXt/MobiFlight command loss — Repeatedly reported — Not reported during Test 1 or the ongoing Test 2
Stationary helicopter/engine idle — Could still exhibit failure — Test 2 remained functional beyond five hours, per operator
Demanding scenery / photogrammetry — Used during testing — Test 1 continued operating, per operator
Simulator Active Pause — Not established as a historical trigger — Test 2: commands remained responsive after Active Pause, per operator
Cause of improvement — Unknown — Not yet established
The operational difference is substantial. It supports continued investigation but does not isolate the cause. In particular, the tests cannot yet establish whether the original issue is a defect in the SimConnect API, a client-side bridge, the realism-mod integration, a WASM component, or an interaction between them.
- Related public reports and technical references
The following links are provided as related cases, not proof of a common root cause:
A. Official MSFS forum — Simconnect CTD’s MSFS24 (December 19, 2024). A user described simulator crashes when using SPAD.neXt or Stream Deck Flight Tracker, with no crashes in their reported comparison without those applications. Other replies reported related behavior. This is a CTD pattern, different from our simulator-running/physical-command-loss pattern.
B. Reddit — Axis and Oh’s won’t connect to MSFS 2024 (November 24, 2024). User reported persistent WAITING FOR SIMCONNECT status; another user reported a similar issue. This is a connection-establishment symptom, not a confirmed long-session drop.
C. Reddit — ChasePlane issue (January 12, 2026). User reported ChasePlane freezing while the simulator remained smooth, and questioned broader FSUIPC/WASM/SimConnect compatibility. This is a potentially closer symptom class, but root cause was not established.
D. SIMiONIC — Small updates, big improvements (January 28, 2025). Official SIMiONIC post states that G1000/G1000 NXi app and bridge updates addressed connection issues, including iPad OS and network connection concerns. This is not a manufacturer admission of a SimConnect core defect.
E. SIMiONIC — About the connections reliability (older article with January 19, 2025 comment). A commenter reported a G1000Bridge repeatedly switching between simulator connection lost and simulator identification. SIMiONIC also discusses network-related possibilities, so this cannot be assumed to share our root cause.
F. SIMiONIC downloads / bridge requirements. Official download documentation identifies the SimConnect library as a G1000Bridge requirement and documents MobiFlight WASM dependency for G1000BridgePC.
G. Official MSFS 2024 SimConnect Inspector documentation. A suitable tool for inspecting SimConnect client/session behavior directly during future tests.
H. Official MSFS 2024 SimConnect SDK. API and debugging reference.
These reports show that SimConnect-related integrations have attracted a range of reliability complaints. They do not establish a single systemic failure shared by all applications or simulator versions.
-
Recommended verification protocol
-
Preserve raw diagnostic records, record checksums, and note exact MSFS, CowanSim, Realism Mod, SPAD.neXt, MobiFlight and WASM bridge versions.
-
Run comparable intervention-enabled and baseline sessions, ideally at least three per condition, spread across normal usage days. Log time to first functional failure and whether it is reproducible.
-
Separately compare Realism Mod enabled versus disabled under otherwise matched conditions. This is especially important because the operator reports that the historical failure did not occur with the mod disabled.
-
Use SimConnect Inspector to capture client presence, request/event traffic, exceptions, and frame updates at the moment of any failure. This is necessary to directly assess SimConnect health.
-
Log a simple standard SimVar (such as altitude) alongside aircraft-specific LVAR/HVAR-driven commands. If the standard SimVar updates while custom commands stop, investigate the aircraft-specific bridge/event layer rather than assuming complete SimConnect failure.
-
Add a timestamped physical-input check (Fire Test, Horn, autopilot commands), and, where feasible, capture the corresponding simulator event/response to measure functional latency and continuity.
-
Capture system resource trends in parallel, but do not infer a memory leak from growth alone.
-
If an interruption occurs, record whether the simulator itself remains responsive, whether both external clients fail, and whether either client reconnects without restarting.
-
Test on a second PC or cockpit if practical before generalizing results or offering a commercial reliability claim.
-
Questions for Asobo and the community
– Has anyone seen two independent SimConnect-connected clients stop responding together while MSFS 2024 remains running?
– Is there a known issue involving extended-session SimConnect requests, callbacks, WASM networking, LVAR/HVAR bridges, or client event dispatch under specific aircraft/mod configurations?
– Are there recommended Inspector counters, logging switches, or traces to distinguish an API-level stall from a client-side event bridge stall?
– Has anyone reproduced a similar symptom specifically with CowanSim H125 v3.3 plus Realism Mod v9.0?
– Would Asobo or other experienced developers be willing to review anonymized diagnostic summaries and a controlled reproduction protocol? -
Proprietary implementation and collaboration
The experimental intervention is proprietary. No details of its implementation, operational mechanism, tooling, or source code are disclosed in this public post. I am open to discussing reproducible observations, high-level test conditions, and appropriately scoped demonstrations. Any commercial or development collaboration can be considered separately.
Conclusion
The original operational issue is real from the operator’s perspective: physical cockpit commands repeatedly stopped working across SPAD.neXt and MobiFlight during long MSFS 2024 sessions. After the proprietary intervention was introduced, the first logged session lasted 4 h 37 min 51 s, and the second session exceeded five hours with continued command functionality reported. These results justify a serious investigation into shared communication dependencies and their interactions with the CowanSim H125 / Realism Mod environment.
The current evidence does not yet isolate a defect in SimConnect’s internal implementation or establish how the experimental intervention relates to the improved stability. That distinction is essential for a useful engineering discussion and for building a testable, broadly applicable solution
────────────────────────────────────────
– This report is an observational field investigation, not a formal peer-reviewed study or an Asobo-confirmed bug diagnosis.