FSUIPC and Mindstar GNS crash

[fabristunt]

Hi,

I'm having a problem with the mindstar GNS 430 and FSUIPC: http://www.avsim.com/topic/497629-gns-430-fpl-crash

Basically, P3D crashes everytime I try to input something in the GPS. The developer suggested disabling FSUIPC and that stops the crashes, but it's hardly a solution at all! He maintains that it's up to the FSUIPC dev or the P3D devs to fix this. 

Having said that this GPS is the worst thing I've ever bought (way too many missing features, something non stated anywhere on their product page), is there anything you can do? It worked with an older version of FSUIPC when I was still using P3D 3.3.5.something, but I don't remember what FSUIPC version number it was...

[Pete Dowson]

12 minutes ago, fabristunt said:

I'm having a problem with the mindstar GNS 430 and FSUIPC

Are they related? Do Mindstar even use FSUIPC?

17 minutes ago, fabristunt said:

The developer suggested disabling FSUIPC

In that case Mindstar are obviously not using FSUIPC. What made Mindstar suggest that step? If they know why it is crashing then such information would obviously help resolve it.

13 minutes ago, fabristunt said:

Basically, P3D crashes everytime I try to input something in the GPS.

What in P3D crashes? Don't you have any information at all, like the actual crash data, the FSUIPC version, the actual build of P3D? Those are really the minimum I'd need to even start looking. An FSUIPC log from such an event would probably help too.

14 minutes ago, fabristunt said:

It worked with an older version of FSUIPC when I was still using P3D 3.3.5.something, but I don't remember what FSUIPC version number it was..

Unfortunately that's not very helpful information then.

Pete

 

[fabristunt]

Thanks for your reply.

I'm using P3D 3.4.9.18400, FSUIPC4 4.958 (crash happened also on  FSUIPC4 4.97) and what crashes is API.dll. I'll post the fsuipc log as soon as I can, which will be in about 2 hours.

I don't know what made Mindstar suggest disabling FSUIPC. If you ask me, I'd say they are clutching at straws. 

 

Here's what they say: 

Quote

 

It is quite literally out of our hands.  There is nothing in our software that's actually crashing.  If our software works without issue with FSUIPC not loaded, then that indicates that FSUIPC is doing something that the sim doesn't like when you build a flight plan in our GNS units.

 

We are in full compliance with the sim's SDK and don't use any hacks/hooks/whatever.  We do that intentionally, so that we know that our code isn't invasive.

 

Got it from here: http://www.avsim.com/topic/497600-530-crashing-on-second-waypoint-entry/?p=3508000

Other people with the same issue.

[Pete Dowson]

14 minutes ago, fabristunt said:

and what crashes is API.dll. I'll post the fsuipc log as soon as I can, which will be in about 2 hours.

API.DLL? That's definitely within P3D.

I suspect the difference between when FSUIPC is loaded and when not is simply related only to the different memory arrangement. without know if MindStar mke use of API.DLL and how, I can''t suggest reasons, but quite often different memory arrangements make the difference between a bad memory access causing a crash and doing little or no harm.

FSUIPC does have access to API.DLL -- it has to put hooks into it for two things:

1. Mouse macros, to intercept the mouse action when making a macro, and
2. for the optional (defaulted off) imConnect text and menu redirection to WideFS clients.

Nothing else.  Assuming you haven't enabled (2), that just leaves the Mouse macro facility. See if that works with and without the Mindstar stuff enabled. Maybe they are hacking into the same area.

Pete

 

[Pete Dowson]

Further to my last message, you can stop FSUIPC using / hacking into API.DLL completely by adding this to the General] section of the FSUIPC4.INI file:

P3Dhacks=9

Try that as well. Let me know.

Pete

 

[fabristunt]

I just tried and it still crashes. I am now trying to understand what to log and what not in the FSUIPC logging tab so I gan give you a LOG that isn't flooded with useless info.

[fabristunt]

Here's an event log. I clicked New Log, then jumped back into the aircraft (A2A C182), turned on the battery and the master avionics, then tryed to insert AAL vor as next waypoint on the FPL page.

 

FSUIPC4.log

[Pete Dowson]

15 minutes ago, fabristunt said:

Here's an event log. I clicked New Log, then jumped back into the aircraft (A2A C182), turned on the battery and the master avionics, then tryed to insert AAL vor as next waypoint on the FPL page

Why click "New Log"? All the essential information at the start is thereby lost.  And please remove all optional logging in the logging tab -- none of that Event logging is useful at all for this. All I wanted was the straight forward default log from the start of the session to the crash. 

And you still haven't posted the Windows crash details.

The fact that it still crashes with no API.DLL involvement by FSUIPC whatsoever (thought I can't see confirmation of this because of you starting a new log and losing that information) indicates it is definitely a problem between Mindstar and P3D's API.DLL -- probablty one of them having an uninitialised variable or bad pointer.

If Mindstar continue to refuse to assist at all I can only suggest you refer it to L-M.  But you will need to supply them at least the Windows crash information. That's a basic essential.

Pete

 

[fabristunt]

Here you are. Sorry for posting the wrong FSUIPC log, I automatically assumed I had to activate something and went for it. I also missed the point where you asked for the windows log. I attached both logs now.

Thanks for your time,

Fabrizio

FSUIPC4.log

Windows crash log.txt

[Pete Dowson]

2 hours ago, fabristunt said:

Here you are.

Ah, that's more useful.

Right. The Windows Crash log isn't directly useful to me, except that it shows that the crash is due to a bad pointer.

The FSUIPC log is useful though. First, this part which shows that two options which use API.DLL are truly omitted (the RED lines here do this for me):

      811 ------ Setting the hooks and direct calls into the simulator ------
      811 --- CONTROLS timer memory location obtained ok
      811 --- SIM1 Frictions access gained
      811 --- FS Controls Table located ok
      811 WARNING: Failed to install Mouse Macro hooks!
      811 --- Wind smoothing fix is installed
      811 --- SimConnect intercept for texts and menus option is off
      811 --- P3D hack inhibits mask = 0009
      811 --- Link check value = 1F6FF (should be 1FFFF)
    
There are other things of interest in the FSUIPC log too. Here's one:

61511 **** SimConnect reconnecting now by request ... ****
    
That means that the special control in FSUIPC to reconnect SimConnect was used. Did you do that? Is so, why? If not, then something you have installed is doing it.

But the biggest clue here is this, right at the end, assuming this is where the crash occurred:

    97298 Advanced Weather Interface Enabled
   144504 .pln

The times I've seen the crash occur after this logging it has always been due to corrupt Weather files -- either the .WX file being loaded, or the WXstationlist.bin file in the same folder as your P3D CFG file.

The reason such corruption only causes crashes when FSUIPC is installed is that it is one of the very few programs which always requests weather data from SimConnect.

There have been lots of threads here about this relatively common cause of crashes in both FS and P3D. Here's a link to one of the most recent ones. I strongly suggest you have a read through it. It has suggestions as to how to verify this (by other FSUIPC INI pararmeters) and what you might do about it:

http://forum.simflight.com/topic/82188-p3d-v335-crash/#comment-495519

The .WX file which was probably used is the one associated with the default flight. i.e. this one:

C:\Users\Fabrizio\AppData\Local\Lockheed Martin\Prepar3D v3\Prepar3D_Default.wx

That and the wxstationlist.bin file can both be safely deleted.  

Pete

 

 

[fabristunt]

I'll read the topic and try deleting the two files this evening. Thanks for your help, I'll let you know if it pans out.

However, this crash is only present if I use the fpl page of the GNS and FSUIPC is active. When flying other airplanes, like for example the NGX, using FSUIPC and mouse macros, there are no problems at all. I'll check the log on one of these flights as well, to check for the weather request.

Thanks again,

Fabrizio

[Pete Dowson]

1 hour ago, fabristunt said:

However, this crash is only present if I use the fpl page of the GNS and FSUIPC is active

It sounds more and more like a Mindstar problem then. FSUIPC knows nothing about what that code is doing. There's really no way I can help. The only folks who can help with working out what is going on when you use that page are Mindstar as they are the only folks who know their code. If they refuse to help I don't know how it'll ever be fixed.

Pete

 

[fabristunt]

Dear Pete Dowson,

I've done as you suggested, and also tried the parameter from the topic you linked. The sim is still crashing. The Mindstart folks, as you call them, are denying the issue. Fact is, the sim crashes only when using their **** GPS.

I think this is enough. Next week I'll buy another GPS addon, the GTN 650 by Flight1. This one looks serious and complete, not a half-assed simulation like some other turned out to be.

Thanks again for your time and your support. I really appreciate that.

All the best,

Fabrizio

[WarpD]

I feel I need to clarify some conclusions drawn in this thread.  The problem is not caused by the Mindstar GNS units.  Lockheed-Martin has confirmed the cause of the crash and it involves the process of getting the sim to use the entered flight plan.  It only shows with FSUIPC enabled, which I believe that FSUIPC indeed peruses the flight plan information from the sim does it not?

Lockheed-Martin will be fixing Prepar3D in a future release to prevent this from happening.

For the record, Mindstar's products do not use any hooks or other methods that step outside the bounds of the officially released SDKs for Microsoft and Lockheed-Martin's products.  As such, our GNS units don't touch API.DLL all of our code works through the panel interface and/or SimConnect and nothing else.  We take this approach with the intent of reducing the chance of our products interfering with normal sim behavior.

Ed Wilson

Senior Developer

Mindstar Aviation

[Pete Dowson]

1 hour ago, WarpD said:

It only shows with FSUIPC enabled, which I believe that FSUIPC indeed peruses the flight plan information from the sim does it not?

It doesn't read the flight pln, it merely has SimConnect notify it when a flight plan is loaded, along with the filename, so it can be placed in the relevant offset for applications to know.

1 hour ago, WarpD said:

 Lockheed-Martin has confirmed the cause of the crash and it involves the process of getting the sim to use the entered flight plan.

Okay, thanks for the clarification. It would have helped if the chap who was suffering the problem had been made aware of this. As it was it appears he thought you were saying it was FSUIPC at fault.

Pete

 

[WarpD]

Pete,

What the individual was told was that the crash was not happening in our software.  It isn't.  They were told that it only happens if FSUIPC is loaded, this is true.  I recommended they discuss it with you and Lockheed-Martin as it was a safer bet that either of you would have a better idea as to why FSUIPC being loaded would cause a crash when a flight plan is injected into the sim.  They apparently don't like being told "we can't fix it" and there's not much I can do about that.

As for notifying them on the issue: we did not have any information from Lockheed-Martin until after this entire thread was completed.  

Ed Wilson

Senior Developer

Mindstar Aviation

[Pete Dowson]

Ok. Thank you for the explanation. Let's hope L-M get it fixed in the next update.

Pete