If the simulator is cleanly shut down, I can expect a SIMCONNECT_RECV_ID_QUIT message, but what if there is a CTD or networking issue and the connection is dropped unexpectedly? The documentation generally only mentions S_OK and S_FAIL, but is there some way to recognize this situation so I can try reconnecting?
(More questions coming up, I’m working on a SimConnect “training”)
When it dies you’ll get a non-OK HRESULT, or an exception in C#, next time you try to use the same handle/instance for new SimConnect call. Usually (from my notes in a C# app) COMException (0xC000014B) = broken pipe (sim crashed/network loss on a Pipe type connection) but not always.
Cheers,
-Max
What is very strange is:
If you activate normal or verbose logging in Simconnect.ini in the sim, you’ll get quite a few of these “Disconnected” log entries right at the beginning, without any indication of what connection it was that opened the port.
There’s something really weird going on with how Simconnect functions, especially at sim startup…
If the sim CTD’s, there’s many different odd states the simconnect connection can get into & it’s essentially impossible to predict every possibility. Ultimately the sim shouldn’t CTD but if it does you have to accept the possibility it’s going to crash your simconnect code also. Over time you can accumulate a variety of checks and hacks in your simconnect app that detect combinations of properties that suggest the sim connection is dead or worse, hung. E.g. including the real PC system time in your windows event loop and having a watchdog timer, but IMHO the vast majority of simconnect apps just expect the DLL to behave as expected. If the simconnect app is simple enough it’ll generally survive a sim crash, but once you start using the full portfolio of simconnect functions a sim CTD can really mess up the app logic.
In my naivety many years ago I briefly thought the simconnect SimCrash event was usefully fired when the sim crashed 
Ok, I’ll agree that the sim shouldn’t CTD, but that is not always up to the sim. More importantly, if I use a network connection (see the documentation) I have that as another potential source of trouble.
SimConnect uses named pipes or network pipes, which both tell you if the connection is lost. There is probably already a valid HRESULT value that corresponds with that, so my question is; do I get an proper error returned and if so, which? Because the client should not crash for something as trivial as a lost connection. Sure it’ll hurt, but crashing SimConnect clients is not acceptable. You catch the situation and provide a proper response, which IMHO should be to wait for the simulator to “return”, followed by a restoration of a valid state.
@EPellissier this is yet again another issue which requires your attention regarding Simconnect.
Thank you so much for letting us revive those threads - they need attention and they haven’t been paid it at all.
I do not observe anything similar when running only the sim with standard content.
The only expected app here is “FCREmbedded” that opens a single connection.
The number between brackets in the line you refer to is the client id.
171.04657 [322] Disconnected! (5, C000014B)
There should be a corresponding “Open” entry with the name of the client app:
116.30831 [322, 1]Open: Version=0x00000006 Name=“AI Objects and Waypoints”
Can you see any of those?
@B21 Regarding client SimConnect calls that cause a crash when the connection is lost, do you have examples in mind?
Regards,
Sylvain
Hi the key issue for me was trying to have robust logic to detect when the sim is no longer functioning, e.g. the registered RecvQuitEventHandler does not necessarily get called if the sim has CTD’d. I have apps (e.g. a flight logger) which can typically be started on Windows startup and then listen for a connect to MSFS 2020 or 2024. The pilot flies, the logger logs the flight into an FAI IGC file, and at some point the pilot quits MSFS and the logger registers the disconnect and goes back to listening for another MSFS connection. With the ‘simple’ logic of using just the disconnect callback to note the MSFS exit, there’s room for my application logic to get snarfed up thinking it’s still connected to the sim (because the simconnect api hasn’t said it isn’t).
So the far more robust approach is to ALSO have a watchdog timer running in the application, that can detect a variety of clues that the simconnect connection is no longer healthy, and the application can quiesce to listening for a new connection cleanly. My C# simconnect apps have had this code in them for quite a while and so far it’s been enough for them to be able to run cleanly indefinitely through multiple MSFS CTD’s. The best example is the flight logger, because it’s understandably frustrating to have the sim crash before completion of a multiplayer competitive task and that’s compounded if my logger hasn’t been able to save the flightlog either.
This generally represents experience and application improvements that most long-time SimConnect devs will evolve through - it’s totally understandable the sim might crash and we should try to code around that. The main thing that would maybe reduce the workload for less experienced simconnect devs would be to have the SimConnect code a bit more reliable at triggering the ‘disconnect’ callback for abnormal sim exits.
I.e. for clarity, I don’t think the main issues I’ve dealt with are ‘connection lost’…‘app calls simconnect’, app/simconnect crash occurs. Mine are the more simple ‘my crappy app code didn’t recover properly when simconnect doesn’t tell me the sim has gone’
Spontaneously, I would use the value returned by SimConnect_CallDispatch. This would need to be confirmed but I don’t think it can fail unless connection was lost.
If the crash occurs in your code, there’s not much we can do.
However, what would be a problem is if some SimConnect functions crash when the connection is lost.
This should be reported as a bug if that happens.
Regards,
Sylvain