RC4 and QW787 D008 Crash

[Jon777]

Hi all.

So as the title says, I've been able to consistently reproduce a D008 crash in the QW787. However the crash seems to be inconsistent in some aspects.

I'm aware that D008 seems to either be an AI traffic or airport issue, I've updated my RC4 database, and changed the TrafficStallTime=5 in FSUIPC6.ini. I use the most recent FSUIPC6 module. I also use an up to date version of AIG.

However despite all of this my RC4 consistently crashes around 1.5-2 hours into a flight from Toronto to Coppenhagen, it seems to be near a specific waypoint that it gets set off, although it can crash in other circumstances as well.

I have a log file though its over 400 mb as it's from the beginning of the flight, and I'm not sure where the crash occurred on the log file.

Finally there was some advice for the QW787 for this type of crash regarding FSUIPC4, but the issue is that those settings don't exist in FSUIPC6.

Long story short it's getting kinda of tiring, cause I can repeat the cause but to do so I have to do a 2 hour from the beginning onwards, only for it to crash. And I do like RC4 especially since it's now free, but this is getting rather annoying.

Signed Jon.

Edited September 26 by Jon777

[John Dowson]

If this is a crash in RC4, I cannot help - you need support from RC4.

2 hours ago, Jon777 said:

Finally there was some advice for the QW787 for this type of crash regarding FSUIPC4, but the issue is that those settings don't exist in FSUIPC6.

What advice? What settings? Do you have a reference/link for this?

Why is this specific to the QW787? If it is specific to this aircraft, shouldn't this issue be fixed in that aircraft?

[Jon777]

27 minutes ago, John Dowson said:

If this is a crash in RC4, I cannot help - you need support from RC4.

What advice? What settings? Do you have a reference/link for this?

Why is this specific to the QW787? If it is specific to this aircraft, shouldn't this issue be fixed in that aircraft?

Well I was directed by Ray Proudfoot from the RC4 forums for help on this issue.

The reference link for the changes in settings, advice, etc.

As to why it's specific to the QW787 I have no clue to be honest. It doesn't strictly appear to be a bug with the QW787 itself, rather from Pete Dowson's post the QW787 tends to aggravate a known issue in RC4, however changes to FSUIPC6 can fix these apparently?

[Ray Proudfoot]

Hi @John Dowson,

I referred Jon to here as it was an FSUIPC error being reported. Jon is advising he can't upload a FSUIPC log as it's 400Mb+

That suggests logging is being enabled. Could that cause a problem in a long flight?

 

[John Dowson]

2 hours ago, Jon777 said:

The reference link for the changes in settings, advice, etc.

Then why not just follow the advice in that post?

5 hours ago, Jon777 said:

Finally there was some advice for the QW787 for this type of crash regarding FSUIPC4, but the issue is that those settings don't exist in FSUIPC6.

But they do - all the settings mentioned in that post are available in FSUIPC6. Why do you think otherwise? Check the documentation.

5 hours ago, Jon777 said:

I have a log file though its over 400 mb as it's from the beginning of the flight, and I'm not sure where the crash occurred on the log file.

If the log file is that big, then you must have some logging settings activated. Turn them off to reduce the log file size. There is no point in me looking at such a large log file, especially as the OP has no idea where the RC4 crash occurred in this file.

41 minutes ago, Ray Proudfoot said:

I referred Jon to here as it was an FSUIPC error being reported. Jon is advising he can't upload a FSUIPC log as it's 400Mb+

That suggests logging is being enabled. Could that cause a problem in a long flight?

Logging should not cause any major issues, except if the disk/add you are logging to runs out of space. Excessive logging may cause some performance issues, but this depends.

But if there are issues, I would usually first like to see a vanilla log file, i.e. with no additional logging activated, and I would advise if I needed any additional logging activated for the issue in question. If a log file is too large to be attached, it should be compressed. If its still too large after compression, then you need to use one of the free file transfer services.

But this seems to be a known issue, and I cannot add any more to what Pete has already said in this post - just follow the advice there, it applies to FSUIPC6 as well as FSUIPC4:

 

[Ray Proudfoot]

Hi John,

Thanks for your post. I should add I'm running the same version of P3D v5.3 and also have the PMDG 777 and use AIG Ai aircraft at 100%. So my setup is very similar to Jon's bar the QW787 which I don't have.

I have never had this problem in RC4. I have already asked him on the RC forum to check is extra logging is occuring. Although it shouldn't cause any problems it does prevent you or me analysing the log. Is searching for Debug=Please the best way to find logging?

[John Dowson]

4 minutes ago, Ray Proudfoot said:

Is searching for Debug=Please the best way to find logging?

No - that is just used for additional/extra logging and should only be added when instructed for investigation of support issues. If that is in the ini file, it can/should be removed, but otherwise just to go to FSUIPC's logging tab and make sure everything is unchecked, and that the Debugging Data field is empty (i.e. is 0 or x0). Further logging can also be performed when the TestOptions ini parameter is used, so if that has been added, that should also be removed.

[Ray Proudfoot]

Thanks John. Been a long time since I used that option.  Hopefully he’s reading your replies here

[Jon777]

I was asking in AVSIM which logging options I should use given the huge size of the initial file.

My initial settings had read/write included in the logging process (that likely cased the huge log file size), cause I figured that since D008 had issues that's how one would catch it. But from what I understand just turn all the logging settings off and create a log file, that should initially catch any issues.

The settings in particular that I can't find in the manual in the advice given by Pete are  UseAIClient and SimConnectStallTime.

Now I presume that SimConnectStallTime has simply been converted to NormalStallTime in FSUIPC6.

However I can't find anything related to UseAIClient in FSUIPC6's advanced user manual. So I don't know what it does, and whether that option has been changed.

Edited September 26 by Jon777

[John Dowson]

1 hour ago, Jon777 said:

The settings in particular that I can't find in the manual in the advice given by Pete are  UseAIClient and SimConnectStallTime.

Now I presume that SimConnectStallTime has simply been converted to NormalStallTime in FSUIPC6.

SimConnectStallTime is now TrafficStallTime - although SimConnectStallTime should still work (for backwards compatibility) although not documented.

UseAIClient  is also still valid, but looks to be not documented. This also goes in the [General] section of your ini file.

1 hour ago, Jon777 said:

I was asking in AVSIM which logging options I should use given the huge size of the initial file.

My initial settings had read/write included in the logging process (that likely cased the huge log file size), cause I figured that since D008 had issues that's how one would catch it. But from what I understand just turn all the logging settings off and create a log file, that should initially catch any issues.

IPC read/write is the logging I would need if I was going to look into this issue, and that does generate a huge log file. But you need to follow that advice in that other post first so you may as well disable logging for the time being.

If that doesn't work, I can maybe take a look at a log file, but we can discuss that if/when needed. This should really be fixed in RC4 (it is RC4 that is crashing after all, not FSUIPC), but I know that is no longer possible.

 

[Jon777]

5 hours ago, John Dowson said:

SimConnectStallTime is now TrafficStallTime - although SimConnectStallTime should still work (for backwards compatibility) although not documented.

UseAIClient  is also still valid, but looks to be not documented. This also goes in the [General] section of your ini file.

IPC read/write is the logging I would need if I was going to look into this issue, and that does generate a huge log file. But you need to follow that advice in that other post first so you may as well disable logging for the time being.

If that doesn't work, I can maybe take a look at a log file, but we can discuss that if/when needed. This should really be fixed in RC4 (it is RC4 that is crashing after all, not FSUIPC), but I know that is no longer possible.

 

What does USAIClient do? Cause I use AI companion and don't want to unnecessarily cause issues with it? And what difference does =No vs =Yes do for UseAIClient?

[John Dowson]

8 hours ago, Jon777 said:

What does USAIClient do? Cause I use AI companion and don't want to unnecessarily cause issues with it? And what difference does =No vs =Yes do for UseAIClient?

When UseAIClient  is set to Yes, a separate dedicated simconnect connection is used for all AI traffic management, and when set to No the main simconnect connection will be used. O don't think this will make much difference but no problems trying this.

This issue does look to be related to AI traffic in RC4, but may be a good idea to confirm this by running a flew flights without AI traffic to see if you get the crash, and then add AI traffic back yo see if the crash returns.

Can you also attach an FSUIPC7.log file from a session when you get a crash, no additional logging required at the moment. Just want to check if there is anything strange reported.

I will also take a look at the other posts on this issue on other forums as this is a known problem.

John

[Ray Proudfoot]

@John Dowson, this is a strange problem because I’m running a very similar setup to Jon.

The main difference is I run AiCompanion on a WideFS laptop and RC on a second WideFS desktop. No problems whatsoever despite Ai being set at 100% with 230+ Ai at a very busy Heathrow. I also use PMDG 777 but not QW787.

Would site of my FSUIPC6.ini help?

[John Dowson]

1 hour ago, Ray Proudfoot said:

The main difference is I run AiCompanion on a WideFS laptop and RC on a second WideFS desktop. No problems whatsoever despite Ai being set at 100% with 230+ Ai at a very busy Heathrow. I also use PMDG 777 but not QW787.

Would site of my FSUIPC6.ini help?

No - as far as I am aware (although I have still not looked into this yet) is that this issue is specific to the QW787 with RC4.

[Ray Proudfoot]

17 minutes ago, John Dowson said:

No - as far as I am aware (although I have still not looked into this yet) is that this issue is specific to the QW787 with RC4.

That’s my conclusion too.

[Jon777]

On 9/27/2024 at 7:37 AM, John Dowson said:

No - as far as I am aware (although I have still not looked into this yet) is that this issue is specific to the QW787 with RC4.

It appears to be unfortunately, which is a shame cause I like the 787.

I've changed TrafficStalltime=5 and also changed NormalStallTime to see if that makes a difference.

I also added AIClient=Yes.

Finally, I'll the log for you, the 400MB one I assume? I know that the crash occurred within 20 minutes of the end of the log. If you don't want the 400MB one I also have a few smaller ones with no options ticked when making the log file, however having read those I don't see any cause of the crash in those ones.

[Jon777]

So did a flight with the changes but flew the 787. Still had a crash. So those aren't fixing it unfortunately.

I'll try it first with the PMDG 777 just to confirm this is a QW787 issue and then if there's no crash I'll try it without AI to see if that contributes to the crash in QW787.

 

[John Dowson]

2 hours ago, Jon777 said:

I'll try it first with the PMDG 777 just to confirm this is a QW787 issue and then if there's no crash I'll try it without AI to see if that contributes to the crash in QW787.

Ok, that sound sensible.

But I don't think there is anything I can do about this issue anyway. It has been around since 2010 at least, and seems to be an issue with RC4 and so needs to be fixed in RC4. If there was a possible fic in this for FSUPC, I would have thought that Pete would have done this a long time ago. Pete was also an RC4 user, and I have no experience with RC4 and so cannot really help much with this issue. I am certainly not going to go through a 400Mb log file to try and understand what RC4 is doing to look into this...!

John