SimConnect behavior on lost connection

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 :slight_smile:

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.