

This can now be done with the FSUIPC version 4.419 or later, using a new additional assignable control called "Re-simconnect". The second workaround is to somehow cause FSUIPC to re-SimConnect AFTER the Mindstar G1000 gauge has initialised. This should work with any version of FSUIPC and the G1000. This gets it initialised before FSUIPC connects. The first workaround which seems to work 100% from our tests is to have the aircraft with the MindStar G1000 loading as part of the default flight. However, because we now know the order is important, there are workarounds. The proper fix must be in Microsoft's hands, but that won't affect FSX (or ESP1). Apart from FSUIPC there aren't that many intense SimConnect users likely to have active SimConnections before the gauge is initialised. It seems that if the SimConnect processes precede the Mindstar G1000 processes in the internal FSX chains, the latter causes FSX to crash as soon as it attempts to file a plan. It also depends upon the ORDER in which the SimConnect clients initialise their links to SimConnect and the MindStar gauge initialises itself. It could actually happen with almost any SimConnect client and the MindStar G1000, but is more likely with FSUIPC because it is the most common and most intensive SimConnect user available.


Can you share any information on the FSX crashing issue when the MindStar G1000 and FSUIPC are both running?Īfter some intensive investigations, it looks to be certain that this is due to a SimConnect bug.
