FSUIPC7 frequently appears to crash when returning to the MFS main menu after completing a flight

[aurel42]

I don't have more information than that. I attached a log and my ini. I'm using Win10 (21H1).

Here's what the Windows Event Viewer has to say:

Faulting application name: FSUIPC7.exe, version: 7.3.0.4, time stamp: 0x627e7a6a
Faulting module name: FSUIPC7.exe, version: 7.3.0.4, time stamp: 0x627e7a6a
Exception code: 0xc0000005
Fault offset: 0x00000000000e6053
Faulting process id: 0x1508
Faulting application start time: 0x01d86f8689880ebd
Faulting application path: C:\FSdata\FSUIPC7\FSUIPC7.exe
Faulting module path: C:\FSdata\FSUIPC7\FSUIPC7.exe
Report Id: 5a89a13f-f377-4d63-a510-bccb372c2b35
Faulting package full name: 
Faulting package-relative application ID: 

How can I provide more useful information?

My workaround: I just restart FSUIPC when this happens.

Cheers,
Marc

FSUIPC7-crash.log FSUIPC7.ini

[John Dowson]

Yes, it does look like its crashing...
Can you enable logging for Extras please, as well as Events and resend the log the next time it crashes.
You can also try setting/changing the following ini parameters in your [General] section:
    TrafficStallTime=-1
    InitialStallTime=45
    NormalStallTime=-1
    StopWAPIInMenu=No

This will reduce the number of simconnect connections used, which can sometimes cause issues.

You also seem to be using the MF event files (and thus the MF event WASM) and are not using the FSUIPC WASM/WAPI for much of anything, that I can tell - unless in your KAP140.mcro file, so you can also try disabling the WASM module as a test.

Regards,

John

[aurel42]

As the first step, I enabled logging of Extras and Events. During one of the following flights, all my FSUIPC controls became unresponsive, while FSUIPC was running and responsive. I don't remember having something like that happen in the past year or so. And it wasn't even a long flight. The log seems to indicate that SimConnect stalled or choked. Exiting and restarting FSUIPC resolved the issue and I could continue the flight.

Next step: I'll set the ini parameters you suggested.

(The attached zip contains the log.)

FSUIPC7-unresponsivecontrols.zip

[John Dowson]

8 hours ago, aurel42 said:

During one of the following flights, all my FSUIPC controls became unresponsive, while FSUIPC was running and responsive. I don't remember having something like that happen in the past year or so. And it wasn't even a long flight. The log seems to indicate that SimConnect stalled or choked.

I can't see any indication of SimConnect issues in your log. When controls become unresponsive, this is usually due to windows putting the controller to sleep. Check the USB hub and device properties and make sure 'Allow the computer to turn off this device to save power' (under Power Management in device properties of Device Manager). Windows has a habit of resetting these settings on occasion. 

[aurel42]

5 hours ago, John Dowson said:

I can't see any indication of SimConnect issues in your log. When controls become unresponsive, this is usually due to windows putting the controller to sleep. Check the USB hub and device properties and make sure 'Allow the computer to turn off this device to save power' (under Power Management in device properties of Device Manager). Windows has a habit of resetting these settings on occasion. 

Hey John, I appreciate your input. Here's how I read the log:

579s: I start taxiing
945s: I'm airborne (tap the brakes, retract gear, engage AP)
1242s: The log stops recording events for SOME reason

Some time after that I pass TOC and I'm trying to set cruise power, but I notice that all my FSUIPC-driven controls stopped working (Warthog throttle, custom throttle quadrant, I think I forgot to check the CH pedals). My yoke is on the same USB hub as the other devices, but it uses its own driver software and is still working. So it's probably not the hub that triggered the problem. It's only been a few minutes since I last touched my controllers, so I can't see why Windows would have turned them off. I do a lot of "unattended flying" for FSEconomy, sometimes not touching anything for an hour or more, and the controllers don't usually stop working.

At this point, I check whether FSUIPC has crashed, but I still get the menu when I click on the FSUIPC icon. I exit FSUIPC using the menu, rename the log, start FSUIPC again and continue the flight with working controls. Not sure how all this would add up to power management issues.

I've been on Win10 21H1 for the longest time ("never change a running system"), but I'm updating to 21H2 now and when that's done, I'll go through all the USB HID devices, making sure that power management is still disabled.

 

[John Dowson]

8 minutes ago, aurel42 said:

I'll go through all the USB HID devices, making sure that power management is still disabled.

I am not going to look into this further until that is done...

FSUIPC receives controller input directly from windows, and then sends this to the sim as controls. It should report an error if there is a problem with simconnect. You could try activating the simconnect log file , and see if any errors are reported there. 

Are you using any other simconnect clients? Have you tried with those changes mentioned previously?

Edited May 26, 2022 by John Dowson
Further info added

[aurel42]

Result of the power management pass: some devices don't have a Power Management tab, some devices have a Power Management tab but the "Allow…" option is greyed out, some devices have the option but it's turned off.

For the remaining devices that have "Allow the computer…" turned on, I look at "Hardware Ids" and google the VID to find the manufacturer (I don't know of another way to identify the device). This way I identify keyboard and mouse, an USB stick, components of my VR headset, the Xbox controller (I only use that for games, not for simming) and, indeed, the Thrustmaster Warthog.

I disabled the Power Management for the Thrustmaster devices, and left it unchanged for the rest.

So, one of the affected devices (the Thrustmaster Warthog throttle) had power management enabled, but it was disabled for the other affected device (my custom throttle quadrant based on a Bodnar interface).

To be honest, from my perspective, this feels like a fluke, some random mishap designed by the universe to confuse the actual issue. I have not encountered this situation in a long time (many, many FSUIPC7 versions ago), I fly almost daily, and it feels unlikely that the problem was triggered by enabling logging for Events and Extras, which is the only thing I changed as I'm trying to get more information about the (frequent) FSUIPC7 crashes this thread is actually about. 😄

 

[aurel42]

50 minutes ago, John Dowson said:

FSUIPC receives controller input directly from windows, and then sends this to the sim as controls. It should report an error if there is a problem with simconnect. You could try activating the simconnect log file , and see if any errors are reported there. 

I will do that if the "unresponsive controls" issue happens again, if that's okay with you. I know that this log grows very rapidly on my system because of the yoke software, see below, so I'd rather not write it for every flight I do, unless it's really necessary.

50 minutes ago, John Dowson said:

Are you using any other simconnect clients? Have you tried with those changes mentioned previously?

Yes, I'm using Little Navmap and the FSEconomy SimConnect client, but I think by far the most stress on SimConnect is created by my force-feedback yoke which reads and writes a couple of variables at a high frequency; it's not assigned to FSUIPC or in-game axes, instead it directly sets AILERON_POSITION etc.

[John Dowson]

Did you check the USB hubs? That is usually where the problem lies...

5 minutes ago, aurel42 said:

I fly almost daily, and it feels unlikely that the problem was triggered by enabling logging for Events and Extras, which is the only thing I changed as I'm trying to get more information about the (frequent) FSUIPC7 crashes this thread is actually about.

Logging should certainly not affect anything...\

Looking at your initial crash log again, are you sure it crashed when returning to the main menu, not when starting another flight?
I ask as this is where you stop the flight/return to main menu:

Quote

  2118672 Sim stopped: average frame rate for last 1935 secs = 36.5 fps
  2118672 -------------------------------------------------------------------
  2120860 C:\Users\marc\AppData\Roaming\Microsoft Flight Simulator\Packages\Community\milviz-aircraft-310\SimObjects\Airplanes\Milviz_310R\aircraft.CFG
  2125188 Lua threads being terminated:
  2125188       1 = "C:\FSdata\FSUIPC7\bodnar_Rotaries.lua"
  2125375 LUA: "C:\FSdata\FSUIPC7\bodnar_Rotaries.lua": killed
  2126141   [INFO]: SimConnect_Close done

and then around 5 minutes later a new flight is started:

Quote

  2472766 Planned flight from KFKN to KCLT
  2472766 C:\Users\marc\AppData\Roaming\Microsoft Flight Simulator\IFR Franklin Mun-Rose (KFKN) to Charlotte Douglas Intl (KCLT).PLN
  2478469 Planned flight from KFKN to KCLT
  2478469 C:\Users\marc\AppData\Roaming\Microsoft Flight Simulator\IFR Franklin Mun-Rose (KFKN) to Charlotte Douglas Intl (KCLT).PLN
  2478532 Sim stopped: average frame rate for last 353 secs = 104.7 fps
  2478532 -------------------------------------------------------------------
  2478547 Starting WAPI...
  2478547   [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.8 (WASM version 0.5.8)
  2478547   [INFO]: Connected to MSFS
  2480969 Planned flight from KFKN to KCLT
  2480969 C:\USERS\MARC\APPDATA\ROAMING\MICROSOFT FLIGHT SIMULATOR\MISSIONS\CUSTOM\CUSTOMFLIGHT\CUSTOMFLIGHT.PLN

Maybe try with Extras logging only (turn off event logging), and set this ini option:
    StopWAPIInMenu=No

If you still get a crash, you could try disabling the WASM to see if its related (if not using it) or activate Debug level logging in the WAPI if you are.

2 minutes ago, aurel42 said:

Yes, I'm using Little Navmap and the FSEconomy SimConnect client, but I think by far the most stress on SimConnect is created by my force-feedback yoke which reads and writes a couple of variables at a high frequency; it's not assigned to FSUIPC or in-game axes, instead it directly sets AILERON_POSITION etc.

Ok, but I don't think its a simconnect issue if FSUIPC is crashing...

Lets see how it goes with this...if the problem persists, I may need to get a crash dump file from you to see what is happening...

John

[aurel42]

29 minutes ago, John Dowson said:

Did you check the USB hubs? That is usually where the problem lies...

I did not. I did now, and they all had Power Management turned on. But if the hub went to sleep, wouldn't that affect all the devices connected to the hub? That would include my keyboard and yoke, they're all connected to the same decent (as in: not cheap, German engineering 😄) USB hub.

I turned off Power Management for all the hubs now (because I don't know where in the "hub hierarchy" the external hub actually resides).

29 minutes ago, John Dowson said:

Looking at your initial crash log again, are you sure it crashed when returning to the main menu, not when starting another flight?

Oh, good point, I should've said "between flights", because I don't know when FSUIPC actually stops doing things. It crashes silently, I only notice the controls not working after I start a new flight, and the FSUIPC icon in the toolbar vanishes when I move the mouse pointer to it.

Yesterday, I set all four options you suggested, including "StopWAPIInMenu=No", and I'll have to do some flying now to see whether I experience another crash.

I don't think I'm using the WASM, I followed the steps to install the "stuff from Mobiflight" and that worked for what I was trying to do.

Just so I know where we're going: are we trying to find out how to avoid the crash, or are we collecting information so we can identify the issue leading to the crash? Either one works for me, just want to know what the focus is on.

 

[John Dowson]

15 minutes ago, aurel42 said:

I don't think I'm using the WASM, I followed the steps to install the "stuff from Mobiflight" and that worked for what I was trying to do.

Yes, you are using the MobiFlight WASM module, not the FSUIPC one. You may as well disable the FSUIPC WASM - you can even uninstall it (i.e. opt not to install it the next time you re-install). But I would like to know why its crashing, so maybe keep it active for now...

17 minutes ago, aurel42 said:

are we trying to find out how to avoid the crash, or are we collecting information so we can identify the issue leading to the crash?

I would prefer the latter...but if we find something that avoids the crash, that should also help in identifying what is causing it...

[John Dowson]

To clarify, I suggest that you first disable the WASM (+ any additional logging) and fly like that for a while.
If it crashes again, we know it isn't related to the WASM (and you can uninstall as not using, but up to you), and I can provide some additional logging flags to help track this down.
If you are happy that its not crashing any more, I would like you to re-enable the WASM once again, and set Debug (or maybe Trace) level logging in the WAPI, and see if we can get more information from the log.

I will also perform some tests here...

[aurel42]

Roger!

[John Dowson]

Hi @aurel42
I found an issue in the WAPI (WASM interface) code that can cause FSUIPC7 to crash in certain circumstances. This is fixed in the attached version if you would like to try it (with the WASM enabled).

John

FSUIPC7.exe

[aurel42]

Since adding "StopWAPIInMenu=No" and, later, removing the WASM folder from Community, I did not experience another crash.

I'll reinstall the latest FSUIPC to restore the WASM folder, and then I'll replace the exe with the file you provided, and I'll let you know if it starts crashing again, or, after a couple of days of flying, if it didn't.

 

[John Dowson]

1 hour ago, aurel42 said:

Since adding "StopWAPIInMenu=No" and, later, removing the WASM folder from Community, I did not experience another crash.

Ok - so this also indicates the issue is/was with the WASM/WAPI.

1 hour ago, aurel42 said:

I'll reinstall the latest FSUIPC to restore the WASM folder, and then I'll replace the exe with the file you provided, and I'll let you know if it starts crashing again, or, after a couple of days of flying, if it didn't.

That would be good, thanks, After you have done this, you can disable the WASM and uninstall it again if you like. Not an issue keeping it installed/running, but may as well remove to save resources if not using.

John

[aurel42]

With the exe you provided, my "lua-driven" rotary switches stopped working. I've enabled lua logging now. I hope to be able to provide more info after another flight.

 

[John Dowson]

That is very strange...that version has been released now as 7.3.6. There was only one change and I can't see how that could effect that...
Please download and try the latest release. If you get the same issue, activate logging for Lua Plugins and set Trace logging for the WAPI (in your FSUIPC7.ini)) and show me the log file as well as the lua script.

 

[aurel42]

Still working on figuring out why the rotaries sometimes work and sometimes don't.

But, while testing, I noticed that 7.3.4 and 7.3.6 both change "TrafficStallTime=-1" to "TrafficStallTime=1". Is that working as intended?

 

[aurel42]

I learned: if I want my Lua script to auto-run, I need to start FSUIPC before I start the flight. If I start FSUIPC while the flight is underway, the rotaries don't work. This behavior is documented in the manual ("whenever the current aircraft is changed (or, indeed, first loaded), or a specific named aircraft (or Profile) is loaded"), I just remembered it wrong, so, while I was testing, I often switched between FSUIPC versions with the plane on the runway, expecting the scripts to be auto-run when they weren't.

I also learned: Because of the behavior of my brand of rotaries (short pulses), or maybe because of my bad coding, the overhead introduced by DebugLua=Yes will render them almost inoperative, only about one in fifty events registers in the sim while Lua logging is active.

You can probably see how I confused myself by upgrading and downgrading FSUIPC, sometimes restarting it while in the MFS menu, sometimes while in flight, sometimes with Lua logging, sometimes without. Sorry!

So, yeah, the rotaries behave exactly the same in 7.3.4 and 7.3.6, and they work when a flight is started with FSUIPC running and Lua logging is off.

[John Dowson]

54 minutes ago, aurel42 said:

7.3.4 and 7.3.6 both change "TrafficStallTime=-1" to "TrafficStallTime=1". Is that working as intended?

Yes, sorry - TrafficStallTime cannot be set to a negative value, my mistake. Set this to 2 or 3 seconds (or higher) if using traffic data. If not, it doesn't matter.

4 minutes ago, aurel42 said:

If I start FSUIPC while the flight is underway, the rotaries don't work. This behavior is documented in the manual ("whenever the current aircraft is changed (or, indeed, first loaded), or a specific named aircraft (or Profile) is loaded"), I just remembered it wrong, so, while I was testing, I often switched between FSUIPC versions with the plane on the runway, expecting the scripts to be auto-run when they weren't.

Hmm. Maybe that is the case - I will check. However, I think that profile specific luas should be started/auto-run when you start FSUIPC with an aircraft already loaded. However, they won't start until the lvars/hvars have been received. I will check this - but next week now, I'm off tomorrow and back next Thursday, so I will check then.

8 minutes ago, aurel42 said:

So, yeah, the rotaries behave exactly the same in 7.3.4 and 7.3.6, and they work when a flight is started with FSUIPC running and Lua logging is off.

Ok, thats good to know, thanks.

John

[aurel42]

I've done a lot of short hops in the past couple of days (Misty Flying Club tours), so plenty of opportunity for FSUIPC to crash, but it was stable like a rock. That's with the WASM module, but also with "StopWAPIInMenu=No". Should I try a couple of flights without "StopWAPIInMenu=No" in the ini, or are we good?

 

[John Dowson]

On 6/4/2022 at 1:13 PM, aurel42 said:

Should I try a couple of flights without "StopWAPIInMenu=No" in the ini, or are we good?

It would be useful to me if you could try without that for a  while, just to see if that is causing issue, as that is currently the default setting, but not essential...

Thanks,

John
 

[aurel42]

Will do and report in a couple of days.

 

[aurel42]

A hardware issue (VR headset being RMA'ed) will keep me from testing in the next two weeks, so even though I did only a couple of consecutive flights (flight - return to main menu - next flight) in the past week, I can happily report back that FSUIPC has not quit on me (that is without "StopWAPIInMenu=No", so basically with the configuration we started out with).

I feel it should've crashed at least once, considering how frequently I ran into the issue before. The bug you found and fixed might just have been what caused FSUIPC to crash on my system.

Thank you! ❤️