This occurs after I have created created all my data definitions and mapped my data. I then request the user sim object before I request the data, but this is never received. Looking at the log, this is because the simconnect connection has been silently disconnected.
My external app uses two simconnect connections (connections 321 and 322), and both are disconnected. I am also running my own WASM module (connection 320) but this is not affected.
This is an occasional error, i.e. happens roughly 30% of the time when I run the app.
Does anyone have any idea what could cause this issue? What is error “(5, C000014B)”? I have seen this error before, returned from SimConnect_CallDispatch in earlier versions of MSFS. I am not receiving this error anymore, it is just reported in the simconnect log file.
My application is not considered malware. Also, as I said, this only happens occasionally.
Ok - how come this error is not reported back to the client via the return status of SimConnect_CallDispatch? If it was, I could take action, but this error is only logged in the SimConnect error log. Other pipe errors (e.g. 0xC00000B0) are returned to the client.
I am reviving this old topic to alert people to possible SimConnect starvation issues. We noticed that on some users, it was impossible to open any new SimConnect connections - we’d receive no SIMCONNECT_ID_OPEN notification - and adding a SimConnect.ini file with verbose output showed an external app continuously getting the DISCONNECTED message for about 20 or so concurrent connections it was trying to open.
The worst part was that it kept trying to call 20 SimConnect_Open’s once per second, exacerbating the issue.
Do you have any advice on how we could prevent this from happening on users’ end?
There is a know issue in all simconnect libraries that once a connection is closed, it cannot be reused. You are therefore always limited to the number of SimConnect clients (or connections) that can be used, defined by the MaxClients parameter of the SimConnect.xml file. I always advise people to set this to the max value, which is 128 (I think) rather than using the default value of 64.
There is nothing else that can be done to prevent this. If you know of such badly behaving clients, you should raise a support issue with the developer.
This issue is also provoked by the use of the EXE.xml file to start 3rd party apps, as when apps are started this way it can take from 30 seconds up to > 5mins for the application to obtain a connection (depending on the contents of the Community folder), and the longer it takes the more connection attempts are made. I think it would be better if the programs started via the EXE.xml file should be delayed until the FS is ready to handle the connections, and the program start-up should be staggered slightly so that the previous program can initialise and get a SimConnect connection before later programs are started.
I wholeheartedly agree with you. The problem can be solved by our good friends at Asobo by:
Delaying exe.xml 3rd party app invocation until the time SimConnect is ready to accept connections
Fixing the bug that does not restore connections back to the pool when they are closed.
We have been alerting 3rd parties we identify who use up a lot of connections when their apps try to reconnect continuously, but it’s not up to us to do that, nor should their apps be permitted to misbehave (and sometimes take up the entire connection pool).
What’s worse, our customers feel that it’s our app that is broken, when it can’t connect to the sim, as sometimes exe.xml will invoke it later than the ones misbehaving - so we end up taking the blame.
We know of your startupdelay workaround in your FSUIPC.ini file, but that is - at best - a workaround which will be unnecessary once the above 2 steps are taken to fix the real issue.
@EPellissier this is a VERY IMPORTANT issue that has been plaguing customers from day one which causes increased support requirements even though the problem stems from Simconnect itself.
tagging you as well here as you were looking at Simconnect-related issues yesterday.
This issue I would rate as the highest of all in terms of importance - can you please take a look at the previous notes? John and I both observe similar in that on a sim which has lots of add-ons (esp. sceneries and other addons which cause a LONG initial load time), when you have a misbehaving external application invoked by exe.xml it will keep trying to invoke SimConnect_Open() as it will timeout a few times while the sim is still loading. This in turn will starve any remaining available Simconnect connections, as even though the max is 64 (by default), the sim will NOT reuse any failed ones at all. The effect is that a SINGLE misbehaving app can cause the sim to not allow ANY simconnect open calls to succeed.
Solution as above, to a) return failed open calls to the pool of available connections, b) to delay any exe.xml calls to external apps until the sim is ready to allow them to connect.
@simfan Although I no longer get the random simconnect disconnects, I am always getting support issues raised on my application not being able to connect due to other badly behaved add-ons consuming all the available simconnect connections.This has been an issue since day 1 and it would be very helpful if this could be addressed with the solutions proposed.
I was not yet able to replicate a situation where closed connections cannot be reused, even by spamming Open calls before the server is ready.
My testing environment is probably not as complex as the one from some of your users who have plenty of external apps installed.
We would need to identify a minimal reproduction case.
Have you collected any SimConnect log generated in such context by any chance?
So far, the only case I could find that will cause problems would be a client that opens plenty of connections and doesn’t close any of them.
Here’s an example of log I generated with FSUIPC installed, and an external app spamming Open calls right without calling corresponding Close, until Open starts to fail: simconnect000_FSUIPC.log (3.1 MB)
Line 13: > 6.38551 [321, 1]Open: Version=0x00000006 Name="Open and Close 0"
Line 14: > 6.38569 [322, 1]Open: Version=0x00000006 Name="FSUIPC.LVAR.WASM"
Line 47: > 6.38619 [323, 1]Open: Version=0x00000006 Name="FCREmbedded"
Line 48: > 6.38621 [324, 1]Open: Version=0x00000006 Name="Open and Close 1"
...
Line 5038: > 6.59879 [382, 1]Open: Version=0x00000006 Name="Open and Close 59"
Line 5045: > 9.02155 [383, 1]Open: Version=0x00000006 Name="Open and Close 60"
Line 13769: > 34.48250 [321, 1]Open: Version=0x00000005 Name="FSUIPC7"
Line 14221: > 35.54898 [324, 1]Open: Version=0x00000005 Name="FSUIPC7_AItraffic"
Open calls kept failing until the server was ready.
Then, my client had the time to open 61 connections, as FCREmbedded and FSUIPC also had the time to open 2 connections.
There’s 1 missing, which I still need to check why.
And then, at timestamp ~34, I closed my app, which closed all open connections (even without any explicit Close calls), allowing FSUIPC to create 2 more.
I need to trace if having 63 connections instead of 64 is the expected behavior, or if this is a symptom of the issue we are looking for.
You might try to install SimAppPro, FSRealistic and NoolAero -
these three are what our customers have identified as biggest offenders in that regard.
Also - you would need to have a lot of sceneries installed so the sim would be sufficiently slow in starting… preferably those with WASM logic embedded.
That is interesting. It is difficult to tell when an open call takes/uses a connection, and when it doesn’t. And you can only close a connection if the connection succeeds and you have a handle to close. In FSUIPC, you can configure the time it waits as the InitialStallTime (including a 0 to wait indefinitely) - if there is no response in this time, the thread is killed (no close possible as no connection received) and a new thread started to try to connect again.
I am surprised that (if) closed connections can be re-used - this has never been the case before, but I must admit that I haven’t tested for this explicitly. Maybe the issue is due to badly behaving clients not actually closing (maybe stalled) connections that have been successfully opened.
I have stopped requesting such logs from users who get this issue (as I know what to advise to avoid), but I will have some somewhere from a few years ago. I will see if I can dig some out - they are very large!.
Unfortunately I am away now until next week - I will try and find some for you then.
@FlyingRaccoon You can probably also test this with FSUIPC. Make sure that you have it auto-started (i.e. via the EXE.xml), and set the DetectToConnectDelayAuto ini paramater to a low number (e.g. 5) and the InitialStallTime also to a low number (try 3 or 4) - both parameter are in the [General] section of the FSUIPC7.ini file.
Helps if you have more add-ons started via the EXE.xml, and quite a few add-ons in your Community folder.
I can take a closer look next week.
Sorry, thats not quite correct. FSUIPC attempts to close the connection from a SimConnect_Open call if the open event is not received in the required time.
You can also add
TestOptions=x800
to the FSUIPC7.ini to log all connection/reconnection information.
Sorry - this won’t work, as I internally force this to be a minimum of 15seconds when FSUIPC is auto-started.
I have ran a few tests and can’t force this issue with FSUIPC alone. I will have to dig out some old simconnect logs from users who reported this issue.
But this was probably caused by badly behaving clients not closing open connections.
I have also seen connection issues caused by the FenixBootsrapper (taking up to 60 connections), although this was a while ago now and may have been fixed.
I can’t force this issue here, using FSUIPC alone. I will reduce my maxClients and check/verify that connections are being re-used.
As mentioned before, we get this a LOT with 2020 clients (FSRealistic still being a culprit for sure - SimAppPro were told about it and have since mitigated the one request every 5 seconds issue).
The biggest problem was the sim itself delaying the starts.