John Dowson

Note there are actually two controls, one to toggle auto-save on/off (auto save must be activated), and another to trigger an auto-save.

I haven't noticed this on my dev system, but I think I have auto-save disabled there. I will check this later. Note that this has always been an issue with more complex add-on aircraft (e.g PMDG), but has not really been an issue before with stock aircraft. Unfortunately I have just removed v5.1 from my systems so cannot compare to that, but I can check the times against my 4.5 installation. Note also that all FSUIPC does is call the SimConnect SDK facility to save the flight, so if there is an issue it is with the SDK and I won't be able to do much, except report to LM. I will let you know. One thing that has been known to cause such issues is anti-virus software, scanning the saved flight file as its being saved. You could check this and add an exception to the saved flights download folder to prevent this. I see Pete has also just replied....

One thing you can try to verify that it is FSUIPC7 crashing (or not, as the case may be) is the following: - start FSUIPC7 manually before you start MSFS - uncheck the option 'Exit with FS' - start MSFS. If you have MSFS set to auto-start FSUIPC7, this will generate an error which you can acknowledge and then ignore - Fly until you get your CTD #When you do that, does MSFS CTD and FSUIPC7 keep running, or does FSUIPC7 exit/crash? If the latter, it is a problem in FSUIPC7 and you should show me your log file. If the former, FSUIPC7 is not crashing but exiting normally as MSFS has crashed, and this needs to be reported to Asobo.

Sorry, but disagree on what? I am still waiting to see your log file from v7.2.0 that you still have not provided. I cannot help you until you show me this file (from when you say FSUIPC7 crashed). Once I've seen that, we can go from there. But any updated version will not necessarily fix your issue, as we do not know where it lies or what is the cause at the moment. It is strange that you ask for help but do not want to provide me with the information so that I can help you with your issue.

No problem with that. Ok, then as suspected the error is being displayed by windows after FSUIPC has exited but before the process has finally stopped. I'm afraid that there isn't anything I can do about this.

Can you try with the attached version please. This will not solve your problem, but will provide additional logging so I can track down where/when this error occurs, although I suspect it may be happening outside of my control.... With this version, can toy please check the contents of the FSUIPC7.log file when you get the pop-up error, and before you acknowledge it. I would like to know what the last message you see in the log is, before you acknowledge the pop-up error message. Thanks. FSUIPC7.exe

This is normal. Many aircraft continually send some controls, which are different for each aircraft. You can use the DontLogThese ini parameter, either in the [General] section of your FSUIPC7.ini, or in your [Profile.xxx] sections. Better to use this in the Profile section as the controls are different for eeach aircraft. Please see the Advanced User Guide for details.

No. And please refrain from hijacking unrelated topics. As the 7.2.0beta has now been released, I am closing this topic.

I'm not sure any additional logging is going to help. There are quite a few reports of this error on google. Some things to try: - if using an in-game overlay (e.g. GeForce experience, etc), then maybe try disabling that - check you are up-to-date with the latest windows updates - update your .Net framework - run the system file checker (run the command sfc /scannow from an admin command prompt) - check your windows Virtual Memory settings Have you always had this error or is this something new? If new, do you know when it started (i.e. after a windows update, an MSFS update, or an FSUIPC7 update?)

That is very strange....I've really no idea what is causing this....Does it also occur if you start FSUIPC7 (without MSFS) and then exit? Yes, no problem! Yes, they are both quite minor. There is nothing I can do about the exe.xml file not working (as it is in the correct format and in the correct place), so you will need Asobo support for that one. This has also been reported before and I couldn't determine why for those cases, so advised to switch back to the old method (i.e. starting FSUIPC7 from the MSFS.bat file, as you now do). I'm not sure what else you can try...I think I'll have to build a special version for you to try with more logging added to the shutdown sequence to see if I can determine where this error is coming from. I'll post an updated FSUIPC7.exe for you to try tomorrow. Cheers - and good night! John

So the EXE.xml is in the linked folder? It should still work - it is quite a standard set-up, I have MSFS also installed on a separate drive. I think you need to raise a support request for Asobo for this, sorry. Ok, thats helpful but also very strange as that means it occurring after everything else has closed down.... Me too! Can you try disabling/unchecking the 'Exit with FS' option. Then when MSFS closes FSUIPC should stay open. Once MSFS has closed, give it a few seconds and then exit FSUIPC. If you do this, do you still get the error, and if so, when?

Nope, still no error for me....very strange....

Ok - I haven't tried with Alt-F4, I'll do that, but presume its the same as closing by quiting thw MSFS main window. Does the same happen when quitting MSFS from FSUIPC (using the MSFS -> Exit oprion)? Doesn't the logging pause when the pop-up error is displayed? Is that displayed before or after the console log window closes? The Exe.xml looks fine. From what folder is it located? Presume you have a MS Store version, and it is under C:\Users\Peter\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache, no? You could try switching to using the SimConnect document type rather than Launch (as I have seen that this is used quite often). Please change your EXE.xml file to the following: If that doesn't work, I have no idea why MSFS is not picking this file up and auto-starting FSUIPC7, sorry. Ok, thanks. What about when exiting MSFS from FSUIPC7? Also, can you let me know when this pop-up error occurs, and what happens when it does. Does the FSUIPC7 window/icon and console window disappear before this message is display, or after? I'm going to try closing with Alt-F4 now to see if that makes a difference....

No, still can't reproduce this error.... Could you activate logging for Extras on FSUIPC, and also activate Debug logging in the WAPI by adding this line to the [WAPI] section of your FSUIPC7.ini file: LogLevel=Debug Could you also have the logging console open when you close down (Log -> Open Console), and let me know what the last message logged is when that error appears. Send me the log and let me know when the error occured. Once thats done, you couldalso try switching to updating lvars from the client (if not doing that already), by adding this line to the [WAPI] section of your FSUIPC7.ini file: LvarUpdateFrequency=6 (that is for 6 updates per second). You should also disable updates from the WASM by setting the following in your FSUIPC_WASM.ini - either in your Packages folder, if you have an FSUIPC_WASM.ini file there, or under the fsuipc-lvar-wasm folder (in your MSFS Community folder) if not): LvarUpdateFrequency=Off This is just to help me track down where the issue lies. It could be a timing problem with SimConnect when closing down (and probably in the WAPI code). Thanks.

Exiting from in a flight or from the MSFS main menu? I have tested using your scripts with the FBW dev and stable and still cannot reproduce. Are you updating lvars from the WASM (the default) or from the client? I'm updating from the client at the moment - I'll switch to using the internal WASM update mechanism (the default) to see if the issue lies there....

You are not starting your luas from the [Auto] section - are you starting them from your ipcReady.lua file? If so, can you please also show me that file as well. Its probably better to start them from an[Auto] section, but it still should not give that error - although I don't know if this is related at the moment. Also, can you try with the FBW stable (and maybe development) version, to see if that makes a difference. Thanks.

I've now added com ro my tests, opening it in each of the 3 luas, polling the com in the poll loop, and closing the com connection in the event.terminate function. This is the log I get when I go from flight back to main menu: And here is the log from exiting MSFS/FSUIPC7 when in a flight: So it seems that all the event.terminate functions are being called in all situations.

Could you show me your FSUIPC7.ini and your 4 lua files (FCU_Speed/Hdg/Alt/VS.lua) and I'll see if I can repeat here. If I can't reproduce, we can try adding extra logging to track down where this is occurring. Its nothing to worry about though, as FSUIPC7 will be exiting anyway. Does it occur every time? Are you using the stable od dev version of the FBW A32NX?

No - thats the changes.txt file that I provide... But this is exactly the same log that you previously posted. Did you not read my last comment? i.e. update to the latest (and only) supported version and try again, and show me the new log file if you get a CTD, together with all Windows Event error logs.

You can try mapping the lvar to an offset and then using the offset spoofing facility, located at offset 0024. This will replace ('spoof') the parking brake offset to the value of the lvar. There is also an example lua script provided that shows you how to use this facility, called liar.lua.

In lua, you can use the event.offsetmask function to trigger a function call when the required bit in the offset changes - see the FSUIPC Lua Library document for details in using this function. In the attached version below, v7.2.1c, I have added the following simvars to offsets: - AUTOPILOT GLIDESLOPE ARM at offset 0x0C7B as a 1 byte flag (unsigned byte) - AUTOPILOT GLIDESLOPE ACTIVE at offset 0x0C7C as a 1 byte flag (unsigned byte) Please let me know if these are working or not, and for which a/c. Thanks, John FSUIPC7.exe

I set up a simple test with 3 luas auto-started, each with an event.terminate function registered that just logs a message when called. When going from a flight to the main menu, this is what I see logged: So, the event.terminate function was called in each script, and each thread was killed after TimeForLuaClosing (2 seconds). So this all seems correct to me. When exiting MSFS from a flight, either from MSFS or from FSUIPC7, I see the following logged: This log shows that the event.terminate function was again called in each script, but there was only one 2s delay (the TimeForLuaClosing ) before all lua threads were killed. Note that these tests were done with a slightly modified version (with additional logging) of the 7.2.1b version I posted yesterday, and I am not using the com library, which can take a while to close down successfully. I can add some com handling and repeat my tests if necessary. So, could you try again with the attached version, and let me know what happens (best to attach your full logs) when you leave a flight to go back to the main menu, and also when in a flight and you exit MSFS/FSUIPC. Thanks. FSUIPC7.exe

Can you not configure the FSUIPC offsets that are used by the acars tracker program? Maybe raise a support request for this to see if this is possible. I can't really consider updating how FSUIPC7 handles the parking brake offset for a single add-on, especially when its still only a development version. I could maybe consider how to handle this in the future, if/when it moves to stable, but I would not consider looking into this while its still in development.

You can map the parking brake state lvar to a free user offset (e.g. 0xA000) using the lvars-to-offsets facility, released in v7.2.0. You would then need to configure the acars tracker program to use that offset instead of offset 0x0BC8 - if you can do that. Offset 0x0BC8 holds the simvar BRAKE PARKING POSITION .There is also another simvar called BRAKE PARKING INDICATOR , but this is not currently held in any offset. If this is updated for the A320 FBW, I could also add that to an offset. However I doubt this is available/populated as the they are using lvars for this now, but I will take a look when I get a chance...

That is a log file from the 5th June. It is incomplete, so looks like FSUIPC7 did crash. However, you are also using an old and now unsupported version of FSUIPC7 - the current (and only supported version) is v7.2.0 - can you please update. Once updated, if you experience your crash again, please show me the log file from the crash + any (and all) error from the Windows Event log + a description of what you were doing (i.e. what were you doing with the MCDU?). Thanks.