FSUIPC and MindStar G1000

[RichardL]

Hello Pete,

Can you share any information on the FSX crashing issue when the MindStar G1000 and FSUIPC are both running?

MindStar (and apparently Microsoft) suspects FSUIPC is causing the crash. I know you have stated in numerous posts here and elsewhere that FSUIPC is not at fault with FSX crashes.

I'm not pointing fingers here, I'm just trying to expedite the resolution of the issue. It is going on four months that I have been unable to use the MindStar G1000 unless I disable FSUIPC. Since I use FSUIPC for axis, switch, button, and rotary integration, disabling FSUIPC is hardly an option.

Best Regards,

Richard

[Pete Dowson]

MindStar (and apparently Microsoft) suspects FSUIPC is causing the crash. I know you have stated in numerous posts here and elsewhere that FSUIPC is not at fault with FSX crashes.

Sorry, I've no idea at all what you are talking about. If folks want to accuse me of sloppy programming they ought to appear and show the evidence.

Pete

[RichardL]

MindStar (and apparently Microsoft) suspects FSUIPC is causing the crash. I know you have stated in numerous posts here and elsewhere that FSUIPC is not at fault with FSX crashes.

Sorry, I've no idea at all what you are talking about. If folks want to accuse me of sloppy programming they ought to appear and show the evidence.

Pete

Hello Pete,

I do agree with you. MindStar has claimed, since this issue appeared, that you have been contacted on a reqular basis. Their claim is that the crashes only happen if FSUIPC is in use so FSUIPC is at fault.

Thank you for the reply,

Best Regards,

Richard

[Pete Dowson]

MindStar has claimed, since this issue appeared, that you have been contacted on a reqular basis.

Ah, yes, a Mr. Poulos. Sorry. That was all done on my side back in October. I forgot the product name.

He even sent a copy of the software to and debug, but this showed it crashing in FSX in some routine they use to retrieve some waypoint data. Here it crashed in the same place both with and without FSUIPC4 installed, but only with the debugger running. That was in Windowed mode. In full screen mode their software locked up my entire PC needing a power re-cycle.

Without the debugger there the problem was reproducible here, but that is of no use as there's no information. There certainly isn't anything at all which points at FSUIPC, except that it occurs far less frequently, if at all, without it.

With the debugger loaded I could get no further than a particular point deep down from their Gauge code, someplace in Windows GDI. Again, there was never any sign of anything to do with FSUIPC being involved. Here are my conclusions, exactly as stated to Mr. Poulos,

Maybe your code includes some fiendish mechanism to prevent hackers, and that detecting a debugger you automatically wreck things? If so I'm not going to be able to help more unless you can disable this.

If not, I am beginning to think that, in fact, the problem you asked me to look at, is this same one, that depending on small variations in the setup, maybe in the memory configuration, this probable stack corruption is allowing you to continue further, or even get over it completely, and that FSUIPC is really just a red herring, possibly worsening the problem due to the amount of other activity (SimConnect-wise only at this stage) and memory usage.

Anyway, without the debugger in control I am able to reproduce what you say (but it isn't a lot of use without the control ofg the debugger). I did, however, manage to get the state of the Call Stack on the predicted crash. That is shown below (2nd pic). From the look of it, the stack is, by then, thoroughly corrupted, so it is impossible to see what is happening where. The actual crash was using a zero values in ESI for indirection.

In neither of these crash conditions does FSUIPC itself appear on the stack. I think FSUIPC itself is incidental, or a catalyst, in this problem, rather than a cause. After all, FSUIPC is not involved in any of the dealings of the gauge or of the graphics manipulations involved. It IS normally notified of a Plan being Loaded or Saved (an event from SimConnect), and that indeed does appear to happen after ENT is pressed follwoing the entry of "PFN". However, the plan filename is empty (I just get ".PLN") -- maybe this is a clue? Maybe you are providing something in FSX with a null pointer or an empty string when it really needs some name, even if only a dummy?

I thought that, possibly, the fact that FSUIPC is asking from PLAN load/save events to be notified, this, with an empty or zero name, might be causing the corruption some place in FSX, so I recompiled without those two events being requested -- but the result was the same, so it isn't that. But I did a version with extra logging for the Plan Loaded event, and this is what I get. Maybe it is relevant, maybe not:

203109 #SIMC FILENAME EVENT: EV=22, Strlen=4, Name=".PLN"

Incidentally, a much more minor matter, but did you know that, immediately on loading, one or other of your gauge(s) send the "TOGGLE_GPS_DRIVES_NAV1" control 19 times? The effect is the same as sending it once. Maybe it is reading it back so quickly it hasn't changed so it tries again?

The stack on the crash shows it deep in Windows, from their Gauge, as you can see in the attached screen grab.

Their claim is that the crashes only happen if FSUIPC is in use so FSUIPC is at fault.

Well, see above. My last exchanges with Mr Poulos ended with him saying that they had taken it up with Microsoft, but the latter have no time to support FSX at present, so he needed to reproduce it with ESP. I sent him ESPIPC and he has managed to reproduce it on ESP too, now. That was a week or so before Christmas. The ESP support team have been away on their break until last week, so Mr. Poulos was going to take it up with them again "in January". I've not heard any more yet.

Regards

Pete

[Pete Dowson]

Can you share any information on the FSX crashing issue when the MindStar G1000 and FSUIPC are both running?

After some intensive investigations, it looks to be certain that this is due to a SimConnect bug.

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.

It also depends upon the ORDER in which the SimConnect clients initialise their links to SimConnect and the MindStar gauge initialises itself. 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. Apart from FSUIPC there aren't that many intense SimConnect users likely to have active SimConnections before the gauge is initialised.

The proper fix must be in Microsoft's hands, but that won't affect FSX (or ESP1). However, because we now know the order is important, there are workarounds.

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. This gets it initialised before FSUIPC connects. This should work with any version of FSUIPC and the G1000.

The second workaround is to somehow cause FSUIPC to re-SimConnect AFTER the Mindstar G1000 gauge has initialised. This can now be done with the FSUIPC version 4.419 or later, using a new additional assignable control called "Re-simconnect". This method should work with any version of the G1000, but only with FSUIPC 4.419 or later. However, it is inconvenient because it requires an extra keystroke or button press by the user, and if he forgetscrash.

So, the third and best workaround is being implemented and tested as I write this, and that is where the Mindstar G1000 gauge forces FSUIPC to re-SimConnect, using a mechanism I've supplied them. This will work with any recent (4.40 or later, please) version of FSUIPC, but obviously needs the updated G1000 from Mindstar. This method will be automatic and the only noticeable side-effect will be some extra FSUIPC log lines saying it is reconnecting to SimConnect. In 4.419 and later this will log as "by request", but in older versions it will log as if SimConnect stalled and had to be restarted.

Note that I only support current versions (4.40 or later at present), so no-one should now be without a solution to this problem.

Regards

Pete

[RichardL]

Thanks Pete. I'll give it a go.

[glassman]

Hi everyone,

I just want to clarify a couple of statements posted in this thread and in our Mindstar Aviation support forum. Unfortuantely, some of the statements can be mistakenly interpreted as implying that we lied to our customers about who we were working with on this problem. I can assure you that we enlisted Pete's excellent help way back in October and several communications were happening between us. Shortly thereafter we decided to take it up with Microsoft which is where the root of the problem appears to be, buried in SimConnect. Since then, we have been in almost daily contact with various people at Microsoft (my bloating inbox can prove that).

Leaving people with the impression that we lied to them is a pet peeve of mine, so it was very important to me that I get this post into this thread and attempt to set the record straight.

Now, on to the problem itself, we believe we see a pattern developing where people who upgrade to our updated G1000 along with FSUIPC 4.40 are still having flight plan problems in the Mindstar G1000, while those who upgrade to the latest FSUIPC beta appear to be fixed. We are waiting to see what else comes of the initial batch of testers on this before we announce to a wider audience that an FSUIPC beta version is required. In either case, it is most important to keep up to date with the lastest release version of FSUIPC since you only get support for the latest version.

Pete also wanted me to be sure everyone knows that upgrading from FSUIPC 4.40 to one of the FSUIPC beta versions is quite different than upgrading your FSUIPC from 4.2 or 4.3 to the beta. The latter requires a full install to keep all the supporting FSUIPC files in sync with the main FSUIPC program.

--Mindstar Aviation