Here’s what Claude says given your screenshot - the TL;DR recommended steps are at the end.
This log is much more informative than a typical “it disconnects” report.
The headline: this is not a connection failure, it’s a connection cycle
The client connects to MSFS 2024 successfully every single time, within milliseconds, then the connection is closed 10–40 seconds later, then it reconnects. Repeatedly.
| Event |
Time (UTC) |
Duration |
| Opened |
21:00:53.953 |
|
| Closed |
21:01:05.062 |
up 11.1s |
| Opened |
21:01:10.182 |
(down 5.1s) |
| Closed |
21:01:49.493 |
up 39.3s |
| Opened |
21:01:58.780 |
(down 9.3s) |
Three full cycles in 75 seconds.
What this rules out immediately
Against the candidate list from before, this kills most of it outright:
- All install/config causes — gone.
Simconnect interface opened succeeds in ~milliseconds, repeatedly. DLLs, VC++ runtime, bitness, elevation, SimConnect.cfg are all provably fine on this machine.
- Startup race (#1) — gone, it connects.
- Slow resource leak (#6) — gone. A leak produces one failure after a long ramp, not a 10-second cycle.
- Network — gone, this is a local pipe; the websocket binds to
localhost:32500 fine.
- Menu/flight-transition (#3) — very unlikely. Nobody returns to the menu three times in 75 seconds.
Also note the first line: 07:24:16 ConnectedToSim -> Broadcasting, then nothing until the app restarts at 21:00:44 — assuming that’s the head of the file, the same machine and install held a connection with zero state churn that morning. The setup is capable of stability. Something differs about the evening session.
Where the close originates
The ordering matters:
[FS2024] connection state changed Closed
[connection] Broadcasting -> Disconnected
The FS2024/SimConnect adapter reports the close first, and the higher-level [connection] state machine merely follows. So this is not SimFly’s broadcast logic deciding to drop — it’s either the sim terminating the client, or SimFly’s own SimConnect wrapper detecting a fault. That narrows it to the sim side or the transport layer.
The strongest lead
Could not extract ICAO from livery 'A350-900 ULR (No Cabin)', leaving ICAO blank
Logged after every reconnect. This is candidate #5 — aircraft-dependent behavior — with a name attached. The “(No Cabin)” variant naming and the ULR designation point to a third-party addon A350 rather than anything stock (most likely iniBuilds, though I’d confirm rather than assume). That’s a heavy WASM aircraft that does substantial SimConnect work of its own.
Two things follow:
- The app is already demonstrably failing to parse this aircraft’s metadata. That’s benign on its own (
[INF], handled by blanking the field), but it proves the aircraft presents non-standard title/livery strings, and it raises the odds that other aircraft-dependent requests are misbehaving too.
- A WASM-heavy addon adds main-thread SimConnect load, which feeds directly into the queue-overrun mechanism.
The single highest-value test: have the user fly a stock aircraft and watch the log. If the Open/Closed churn stops, it’s the aircraft, and you have your answer in five minutes.
Two other things worth flagging
Their alert is set to never fire. Broadcast Alert timeout is 120 seconds, but the longest gap here is 9.3s. The user gets no warning at all — the problem is completely invisible from the UI, which is likely why it reads as vague intermittency rather than a hard fault. Have them drop it to ~20s to make it observable, and to measure whether it’s improving.
The reconnect gaps look like a fixed ~5s retry. 5.1s is one poll; 9.3s is two, implying an attempt around 21:01:54 that failed silently and isn’t logged. Minor, but it hints the sim was briefly not accepting connections — which would point at the sim being busy rather than SimFly being at fault.
The log level is the real obstacle. Every line is [INF] — there are no WARN/ERROR entries, no SimConnect exception messages, and 32 seconds of complete silence before the second close. Nothing in this log states why the connection closed, because that log level doesn’t record it.
On the visible symptom
The ATTENTION: The flight never took off dialog and the 0.00 NM on an active flight created 2h27m ago are consistent with a tracking session that never accumulates enough continuous data to register a departure. I’d treat that as the downstream consequence rather than a separate issue — though note the app was only started at 21:00:44, well after the flight was created, so some of that gap is simply the client not running.
What I’d do next, in order
- Stock aircraft test. Isolates the A350 in one flight. Cheapest, highest information.
- Enable SimConnect server logging (
SimConnect.ini in the sim’s install folder) to capture the actual close reason from the server’s side. This converts the whole hypothesis list into a fact.
- Ask SimFly support for a debug/verbose log level — the current output can’t distinguish server-terminated from client-terminated.
- Ask what else was running at 21:00 that wasn’t at 07:24. Other SimConnect clients, and whether they survived the same window.
- Population check: pull the same log from the other affected users and look for two markers — the Open/Closed churn signature, and a non-stock aircraft in the ICAO warning. If the affected users share an aircraft rather than a hardware profile, that confirms it.
Worth noting as a weak variable: Windows NT 10.0.26220.0 is a Windows 11 Insider build. Probably irrelevant, but if the affected users cluster on Insider builds that’s worth knowing.