John Dowson

👍

See the following FAQ entry for this issue: Check your InstallFSUIPC7.log file for any issues/errors, and check the contents of the EXE.xml file to make sure it is valid. Usually such issues are caused by another add-on writing a corrupt EXE.xml file. If that is the case, just delete that file and re-install. You can post / attach both files here and I can take a look.

Thanks for the update. Previously windows would ask for a new username/password if the account couldn't be elevated correctly so this behavior must be relatively new... I will add a section in the Installation guide about this issue. Anyway, glad its now working! Regards, John

And how did you solve it then? It is not a WASM or FSUIPC issue. Check the Asobo forums for similar reports. That is very strange... I was going to suggest monitoring the pause state in case that has been triggered, but if that was the case you wouldn't see this. Can you set logging for Events in FSUIPC, and when this happens again show me the FSUIPC7.log file (after exiting). So esc doesn't work? What about the FSUIPC option MSFS->Exit?

What actually happens when you proceed? Is an InstallFSUIPC7.log file created, and if so can you please attach it. Do you have a UserCfg.opt file under: %APPDATA%\Microsoft Flight Simulator\UserCfg.opt? If not, where is this file located? In that file, what is the setting of the InstalledPackagesPath variable at the end of the file? Is your APPDATA environment variable set correctly?

Ok, so MSFS froze? If so, how did you close it? Does FSUIPC still work? Via the FSUIPC_WASM.ini file - see the documentation (WASM section in Advanced User guide). It sounds like your issue is with MSFS, not the FSUIPC WASM. If MSFS has frozen, so will the FSUIPC WASM module. If the WASM module crashes, MSFS should go on regardless,,, Note also that there were very few changes from 7.5.0 to 7.5.1, and no changes at all in the WASM. I suspect your issue may have been caused by a sim update that happened at about the same time.

What does this mean? Deleted what changes? This makes no sense... Why do you think the WASM had crashed? Was MSFS still running when you attached that file? If so, please always exit MSFS before attaching a WASM log file. If the WASM did crash, it certainly didn't crash when scanning for lvars and I will need more information . Please set Debug level logging in the WASM and show me a log file with that enabled, and attached after exiting MSFS. Also please set Debug level logging in the WAPI (FSUIPC menu bar, Log -> WAPI -> Debug) and attach your FSUIPC7.log file as well as your FSUIPC_WASM.log file.

It really helps if you can be more specific about what actually happens. What should happen straight away after starting the installer is that a windows box should appear asking if the application (from an unknown publisher) can make changes to your system. You should then click Yes, which then gives the installer elevated privileges and starts the installer. Then, it shows the welcome page, you cluck Next and if you have both MSFS2020 and MSFS2024 installed, it should show a screen that allows you to select the version, otherwise it goes to the license agreement page. What do you see? What versions of MSFS do you have installed, and are they via Steam or MS Store?

You say your WASM is crashing. I therefore need to see a log file for this, preferably with Debug level logging enabled. There is no point attaching a log file from a session where it didn't crash.

The log file shows that FSUIPC7 exited as MSFS had quit: Are you saying that MSFS was still running? If so, try setting DisableMSFSMonitor=Enum in the [General] section of your FSUIPC7.ini file. This is needed (and added automatically) in Windows 11, but shouldn't really be needed in Windows 10. However, if FSUIPC can no longer see MSFS and thinks it has exited, then you should try with this set. Otherwise, you could disable the auto-exit feature (uncheck Options -> Exit with FS).

What do you mean by this? How do you know it has stopped? How do you restart it? Do you have to kill it first? The log file you attached ends after 5 seconds, and shows FSUIPC still running after being started at 14:25...did you attach the wrong file? If you restarted FSUIPC, it would be the FSUIPC7_prev.log i would need to see.... If it is presets that stop working, you could be suffering from a WASM crash, but then restarting FSUIPC would have no effect. I really need more information and a log file from when this occurs.

That looks ok but could be cleaner, and some of the numbers are incorrect... You don't need to test check_lights for 0 - just set it to 0 and use variables local to the function, e,g, Logo lights are bit 8, so 2^8=256, so should be: Also wing lights are 2^7 = 128, etc...

All such connection issues, especially after a windows update, are usually due to either Workgroup name changes of firewalls being reset. So please double check these - the Workgroup name on both PCs, and try disabling ALL firewalls - client, server and router, to see if that makes a difference. Also, please attach your WideClient.ini for such issues, and always exit P3D/FSUIPC before attaching files. Have you tried setting the ServerName (or ServerIPAddr) and Protocol WideClient ini parameters? If not, please try that. Please review the section Configure your Network in the WideFS User guide, If running as Admin, you may need to run WideClient as Admin as well...

What FSUIPC crashes? If FSUIPC is crashing, please show me / attach your FSUIPC7.log file and also show me the the information from the windows crash event (from the Event viewer). Well, 7.1 is very old now - do you mean 7.5.1? Where is your windows Documents folder located? The uninstall log file shows that there were errors trying to remove these: If there are issues installing the Documentation, this is usually due to either an incorrect set-up or a OneDrive issue. The location of the Documents folder is taken from your registry, so check the Personal key under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders Try a clean install. First, manually run the uninstaller to remove FSUIPC7 (from the windows app management panel, or by double-clicking the uninstaller in Explorer). Then try installing again. Accept all the defaults and show me the InstallFSUIPC7.log file from this attempt and let me know what happened. Then, if there were any errors, manually run the uninstaller again, and then re-run the installer. this time, deselect the documentation components. Does it now install? Show me the InstallFSUIPC7.log file from this attempt as well.

There are lots if reports of CTDs with MSFS2024 - these are nothing to do with FSUIPC7. When you tun the installer, it should detect the previous installation and remove this, including the documents. If they are not removed, then this is usually because they are open somewhere. Did the previous version not het uninstalled correctly? Any problems with installation, you can show me / attach the UninstallFSUIPC7.log file (which is the log of the previous version uninstalled) and also the InstallFSUIPC7.log. But just try again first (i.e. re-run the installer), and make sure that no documents are open when you do this.

But you don't need to do this. Once you have validated your key, and FSUIPC7.key file is created whuch contains your key details, and when you update/re-install, you should just skip the license validation page. But your key details should be pre-populated (from your FSUIPC7.key file) and you should be able to re-validate them without a problem. If your key previously validated but no longer does, then either you entered them incorrectly or maybe anti-virus software is interfering. If they previously validated, then your VC++ redistributables must be ok. But please see the Installation and Registration guide for all registration issues,

There is no problem with the latest version of FSUIPC. There is probably an issue with the software you are using that is reading offset 0x3308 which holds the FS version number. This held 13 at start-up in all versions of FSUIPC7 prior to 7.5. However, as 7.5 is compatible with both MSFS2020 and MSFS2020, the version number is no longer written to this offset until FSUIPC has connected to the FS, as it needs to determine the version first. This has caused some issues with some 3rd party software. To help with this, I released 7.5.1 which contains a couple of additions to help with this. If you add: Init3308=13 to the [General] section of your FSUIPC7.ini file, then FSUIPC will again pre-populate that offset with the value 13, which is for MSFS2020.

That may be ok or could be too high. You should either tune that parameter or let FSUIPC tune this for you. See the section Auto-tuning of initial start-up ini parameters in the Advanced User guide, Also, from the User Manual on page 7:

The "reading result from another lvar", is that referring to Q400_YD_LIGHT ? No - I was referring to L:MJC_VAR_READ_VALUE - the readXMLIF function writes the result to that lvar, which is then used to set the actual lvar value (Q400_YD_LIGHT, Q400_AP_LIGHT, etc) . That should be fine, but better to drop the userParameter value (as its not being used (to avoid confusion) or just pass in 0: function yd_on (var, value, userParameter) ipc.writeUB ("66C0", value) end event.Lvar ("L:Q400_YD_LIGHT", 100, "yd_on", 0) Yes, Luas that wait for events always need to be started, and usually via the [Auto] or profile-specific [Auto.xxx] section.

No it didn't... The END OF PROGRAM line means that the WASM exited normally as MSFS exited. The errors occur as the WASM is trying to clear things up nicely before exiting but the simconnect connection is dead. Those are nothing to worry about. So the WASM isn't crashing - why do you think it is?

Ok, but you should at least show me your files...these are what I need to at least have some understanding of your issue - I cannot really help at all without seeing those... And a Merry Christmas and Happy New Year to you as well! Cheers, John

Have you assigned in ProSim or in FSUIPC? If its not responding, activate logging for Buttons & Keys as well as Events, and show me / attach your FSUIPC6.log and FSUIPC6.ini files, the latter showing your issue. I can take a look to see if I can see anything strange, but this depends how/where you have assigned. Note that support will be slow over the Christmas/New Year period, as I am also now on holiday and need a break.... John

Btw, why did this issue start only "lately"? Do you know what changed to provoke this issue?

There was no change at all in the WASM between 7.5.0 and 7.5.1, so if its now crashing more frequently then this is most likely due to a sim update. Did you check your WASM ini settings? If you have followed the advice in that post and are still seeing a WASM crash, please show me / attach your FSUIPC_WASM.log file.

There is no state to the push buttons, they just trigger custom controls: #define EVT_EFIS_CPT_WXR (THIRD_PARTY_EVENT_ID_MIN + 369) #define EVT_EFIS_CPT_STA (THIRD_PARTY_EVENT_ID_MIN + 370) #define EVT_EFIS_CPT_WPT (THIRD_PARTY_EVENT_ID_MIN + 371) #define EVT_EFIS_CPT_ARPT (THIRD_PARTY_EVENT_ID_MIN + 372) #define EVT_EFIS_CPT_DATA (THIRD_PARTY_EVENT_ID_MIN + 373) #define EVT_EFIS_CPT_POS (THIRD_PARTY_EVENT_ID_MIN + 374) #define EVT_EFIS_CPT_TERR (THIRD_PARTY_EVENT_ID_MIN + 375) #define EVT_EFIS_CPT_LAST EVT_EFIS_CPT_TERR ... #define EVT_EFIS_FO_WXR (THIRD_PARTY_EVENT_ID_MIN + 425) #define EVT_EFIS_FO_STA (THIRD_PARTY_EVENT_ID_MIN + 426) #define EVT_EFIS_FO_WPT (THIRD_PARTY_EVENT_ID_MIN + 427) #define EVT_EFIS_FO_ARPT (THIRD_PARTY_EVENT_ID_MIN + 428) #define EVT_EFIS_FO_DATA (THIRD_PARTY_EVENT_ID_MIN + 429) #define EVT_EFIS_FO_POS (THIRD_PARTY_EVENT_ID_MIN + 430) #define EVT_EFIS_FO_TERR (THIRD_PARTY_EVENT_ID_MIN + 431) #define EVT_EFIS_FO_LAST EVT_EFIS_FO_TERR See the FAQ section on how to use PMDG custom controls: John