Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hi John,

P3D v5.4 running FSUIPC v6.2.0 flying the PMDG737NGXu.

My flight today was from Helsinki to Heathrow. A couple of minutes after take-off the sim locked for 40 seconds before recovering. A short while later it hung for nearly 4 minutes but again, recovered.

For the remainder of the 2hr 20m flight to Heathrow it was fine. I'm attaching two logs showing FSUIPC's reaction to the lockups. Have you seen anything like this before and do you have an idea why it might be happening?

I'm also attaching a log from a flight yesterday when I was flying a twin-engne prop. I didn't notice any lockups but they're logged but of much shorter duration.

The reason the previous autosave files weren't there is because I delete them as part of a clean-up when importing the latest flight plan.

Would extra logging identify where the problem lies?

P3Dv5_Hang.jpg

FSUIPC6_prev.log.txt FSUIPC6.log

Posted
1 hour ago, Ray Proudfoot said:

My flight today was from Helsinki to Heathrow. A couple of minutes after take-off the sim locked for 40 seconds before recovering. A short while later it hung for nearly 4 minutes but again, recovered.

For the remainder of the 2hr 20m flight to Heathrow it was fine. I'm attaching two logs showing FSUIPC's reaction to the lockups. Have you seen anything like this before and do you have an idea why it might be happening?

Long pauses with PMDG are almost always due to auto-save, and these are getting worse as Microsoft increases anti-virus protection. You need to exclude various folders from anti-virus scanning. See 

 

Posted
7 minutes ago, John Dowson said:

Long pauses with PMDG are almost always due to auto-save, and these are getting worse as Microsoft increases anti-virus protection. You need to exclude various folders from anti-virus scanning. See 

I suspect you've forgotten our conversation a few weeks ago on this very subject. I excluded all the file types, folders and executables and also fsuipc6.dll but they still persist.

Maybe I've missed one but I don't know which. I'll ask on their forum.

Out of interest does the first autosave do anything differently to the rest? I ask because these lockups are always around the beginning of the flight, never in the middle or end.

How long is the gap in seconds between 217609 and 218172. That was the gap on a Lear25 flight I've just completed. No visible delay noticed.

Posted

Hi John,

I've just tried a short flight in the DA62 with Autosave turned off. The log reveals nothing unusual. Looks like the problems are linked to autosave but trying to establish why the sim locks for a few minutes will take some time.

At least I can reassure myself it's nothing more serious.

Posted

Hi Ray,

1 hour ago, Ray Proudfoot said:

I suspect you've forgotten our conversation a few weeks ago on this very subject. I excluded all the file types, folders and executables and also fsuipc6.dll but they still persist.

No, I haven't forgotten... I didn't realise it was you posting, was in a rush and just fired off a stock response for such issues when using PMDG aircraft.

1 hour ago, Ray Proudfoot said:

Out of interest does the first autosave do anything differently to the rest?

Not as far as FSUIPC is concerned - it just calls the simconnect function to save the flight each time an auto-save is performed.

1 hour ago, Ray Proudfoot said:

How long is the gap in seconds between 217609 and 218172.

The timestamps are milliseconds since start, so the difference between them is just over half a second.

8 minutes ago, Ray Proudfoot said:

Looks like the problems are linked to autosave but trying to establish why the sim locks for a few minutes will take some time.

You can try logging auto-save and either keep the logging console open or take a look at the log file when you get a pause, and this should tell you if its related to auto-save or not. To log auto-save, add the following to the [General] section of your FSUIPC6.ini file:
    Debug=Please
    LogExtras=x4

Are you using the traffic limiter? If so, as its only happening at the start of a flight, presumably when there is lots of AI traffic injected, maybe it is related to this, with FSUIPC trying to remove traffic that is continually getting injected? Just a thought (and I can't remember this ever causing issues before) - you can also log the traffic limiter by using a LogExtras value of x100 (or x104 for logging both auto-save and the traffic limiter).

Otherwise I am not sure what to advise. Is this a new issue?

Cheers,

John

Posted

Hi John, thanks for your reply. To start at the end it’s only been an issue in the last few weeks but almost certainly linked to autosave because I had a P3D crash and wanted to load from a saved flight only to realise it wasn’t turned on. I think the problems started after that.

The fact it’s happening with all aircraft only became clear today by checking the FSUIPC log. At half a second I was never going to spot that delay.

The flight out of Helsinki this morning had Ai well below the limit of 160 so we can discount that.

I forgot there’s a Radar Contact file (rc4) saved too so I’ve added that to the exclusion list.

I had turned off Live Virus Protection last week and went 3 days without a problem but then it returned so I turned Live protection back on. Strange it would happen with that off.

I’ll add the extra logging and hopefully that will reveal what is causing the issue. But if nothing else I can live with it knowing where the problem lies. But it would be nice to fix it since the sim and computer is great in all other respects.

One suggestion. It would be helpful if the call to autosave was logged so users can see immediately if the problem is definitely associated with it.

Posted
3 minutes ago, Ray Proudfoot said:

One suggestion. It would be helpful if the call to autosave was logged so users can see immediately if the problem is definitely associated with it.

It is logged if you ask FSUIPC to log this, as I have advised. It is not something that should be always logged...well, its been like this for 15+ years so I don't think this needs to be changed now! If you want this logged, just keep those additional logging directives in your ini.

Cheers,

John

  • Like 1
Posted

Hi John,

I set the logging options as you advised and added more exclusions to Windows Virus including PMDG DLL folder.

A flight from Manchester to Heathrow had autosave set every 3 minutes. After 6 minutes flying with no issues I was feeling happy. The flight continued all the way to 3 miles out from 27R and then there was a very long lockup over 3 minutes. That's extraordinary. But it resumed and I was able to land, taxi and park.

I'm attaching the EFB log showing the disconnect plus fsuipc6 log which I don't think shows anything as the sim time didn't change during the lockup.

I displayed Task Manager - Performance and all 24 cores with the exception of 0, 2 and 4 were set at 100%. Those 3 are set in prepar3d.cfg for the main threads.

If there's anything you can spot I'd be grateful.

serverLogfile.txt FSUIPC6.log

Posted

Is the lock-up at the same time as the EFB disconnect from FSUIPC:

Quote

2023-12-13 11:04:53.506   Debug   : Begin disconnect FSUIPC
2023-12-13 11:04:53.507   Debug   : FSUIPC successfully disconnected
2023-12-13 11:07:50.935   Debug   : FSUIPC successfully connected

?

Why is the EFB disconnecting from FSUIPC? Is this because the EFB thinks the sim or FSUIPC has stopped (due to the pause/lockup)?

28 minutes ago, Ray Proudfoot said:

I don't think shows anything as the sim time didn't change during the lockup.

If the sim time didn't change, then the FS certainly froze during that period, However, as FSUUIPC didn't try and re-connect (or log a data stalled message), it must either have been still receiving data, or, more likely, it was also stalled/locked up.

33 minutes ago, Ray Proudfoot said:

I displayed Task Manager - Performance and all 24 cores with the exception of 0, 2 and 4 were set at 100%.

That is also worrying - do you know what was using all those cores? Have you checked for any windows events around the time of the pause?

Sorry Ray, but I don't know what to advise. I certainly don't think this is anything to do with FSUIPC. Maybe check the P3D or AVSim forums for similar issues.

Posted

Hi John. Yes, the lockup and disconnect occurred together. I was monitoring the EFB log and it was fine up to the freeze.

The EFB server log is from the P3D computer and the map display is on a networked PC. It seems to me P3D is effectively blocking all outputs until the program causing the freeze has finished doing what it’s doing.

I think FSUIPC is frozen along with P3D.

I’ve asked on the Microsoft Windows forum with help in using ProcMon to see what process is causing the issue. On a return flight to Manchester I did a manual save and it took no time at all.

I don’t think it’s PMDG, FSUIPC or even P3D. I blame Windows 11 and its aggressive protection. For now I’m leaving autosave off until I can get a resolution.

Thanks for your help.

Posted

I paused the sim whilst I had lunch and when I returned I unpaused it and within 3 minutes it had frozen. After 7 mins it hadn't recovered so I shut it down.

No autosave enabled so it's definitely not associated with that. This time only the main core0 VP was 100%. All others ticking over.

No idea what is responsible. So frustrating.

Posted

Yes, very strange. You could try logging all simconnect data, to see if that is still being received when you get this pause/hang, or what the last data was. The LogExtras value for that is x400. The log file can/will get pretty large with this though. Also maybe event logging.

Did you check for any windows events (in the Event Viewer) around the time this occurred?

Posted

Hi John,

I've set x400 in fsuipc6.ini. Where is the simconnect log held?

I checked this morning in Event Viewer and absolutely nothing around the time of the freeze. Loads of entries for things I'm not bothered about!

Event Logging service is already running. I'll try the MAN-LON flight again and see if I can get the freeze to happen. I have time syncronising enabled in FSUIPC. Could that be a factor?

Posted
3 minutes ago, Ray Proudfoot said:

I've set x400 in fsuipc6.ini. Where is the simconnect log held?

That logs to the FSUIPC6.log file. The simconnect log is a different log, which will log all simconnect activity, i.e. for all apps/processes that use SimConnect. To activate this log, see 

 

5 minutes ago, Ray Proudfoot said:

I have time syncronising enabled in FSUIPC. Could that be a factor?

I can't see how that could affect anything.

Posted

I reflew EGLL-EGCC and as well as logging simconnect I also added the following to Exclusions in Defender Antivirus.

AS CloudArt.exe

Aivlasoft EFB Server.exe (that's the program that created the log showing fsuipc disconnect / reconnect)

It was the first successful flight between the two airports in 4 attempts. I can't think why any of those files I've excluded might impact on P3D but for now I'll stick with these settings (autosave enabled + time sync) and see how I get on with the PMDG.

Simconnect generated a 2.1Gb file and I don't understand any of it. 🙂

Posted

John, I just checked the FSUIPC6.log following that successful flight. I searched the large file for Mode: FREEZE_ATT on FREEZE_ALT on FREEZE_LATLON

but there weren’t any instances found. 👍

Posted
16 hours ago, Ray Proudfoot said:

It was the first successful flight between the two airports in 4 attempts. I can't think why any of those files I've excluded might impact on P3D but for now I'll stick with these settings (autosave enabled + time sync) and see how I get on with the PMDG.

Ok, let me know how it goes.

13 hours ago, Ray Proudfoot said:

I just checked the FSUIPC6.log following that successful flight. I searched the large file for Mode: FREEZE_ATT on FREEZE_ALT on FREEZE_LATLON

but there weren’t any instances found. 👍

But why would you expect to find any of these, especially in a successful flight? When you get a pause, I doubt very much that it is to do with having those events being sent....!

 

Posted
2 hours ago, John Dowson said:

But why would you expect to find any of these, especially in a successful flight? When you get a pause, I doubt very much that it is to do with having those events being sent....!

When I flew light aircraft there were a couple of those in a flight that appeared normal to me. The pauses were less than 1 second. Very different to the PMDG737 experience. That's why I checked just in case there were small pauses.

I've just completed EGLL-EGCC and no issues. That's two flights on the same route without problems. What's the difference to others? Radar Contact wasn't running. I can't see how that would be a factor especially when it's running via WideFS on a separate computer. I know your not a user of RC but could a program running on another computer be an issue?

I'll try the same flight but with RC4 running this time.

Posted

Just completed EGLL-EGCC with RC4 running. No issues. I'm wary of saying it's fixed but this is three successful flights now. What's changed since my last freeze?

Yesterday I added AS Cloud Art.exe to the exclusion list. Why should that make a difference? Well I never had a lockup when on the ground at either end of a flight. They only occurred when airborne.

I don't know if weather changes when on the ground. If it changes as soon as the aircraft is airborne that would explain one freeze as soon as the wheels left the ground at Schiphol and also when 3 miles out at Heathrow. Plus random freezes during a flight which weren't replicated with a load of a saved flight.

Why should this be a factor when it never was on my old computer? Well I have cloud textures at maximum now with the 4090 whereas with the 1080Ti I had them at more moderate levels. Maybe it's the change of that which has made the difference. I can't think of any other reason for these random freezes. Weather loads are random, freezes were random.

Of course this theory could be blown out of the water on my next flight. But the logic makes sense. What do you think?

Posted

I don't think weather updates can cause such long pauses. I haven't used AS in quite a while now, but can't you also log weather updates? You could check the AS logs to see if any updates are in progress when you get this freeze.

Sim pauses/freezes are and have always been an ongoing issue in all sims. I can only look to check that this is not caused by FSUIPC, I cannot really help in tracking down other causes, I am just too busy and don't have the time for this.

Cheers,

John

Posted

Hi John. I have only one log saved so those from failed flights aren’t available. I’ve just completed another flight and during it I changed the update period from 30 to 20 mins.

An update then occurred and the sim was fine. I can only think it’s a rare combination of settings causing it.

That’s four flights now without issues. I’ll report this to Damian over at Hi-Fi. I’m grateful for your help and won’t bother you again. I wanted to post here just in case it might help others.

Posted

But why report to Damian/Hi-Fi as it could be nothing to do with AS? As a developer. it is very annoying when people keep pointing the finger at your software as the culprit for some strange issue that is not at all related to the software that you provide. I get this all the time, and it is very frustrating as well as being quite time consuming.

My suspicion is that it is either windows or P3D, but with these types of issues it is incredibly difficult to determine the cause, and quite often they disappear as easily as they appear.
I has an issue last year that caused my flight sim PC to pause for several minutes, and then my system was auto-rebooted, with no logs or errors reported anywhere. This lasted for 6 months without resolution. I don't have this problem anymore, but I suspect it was a GC card/driver issue. 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.