John Dowson

This is very confusing...are you also installing/replacing the layout.json file that I provide with each WASM update (in the folder one-up from the WASM itself)? The attached WASM has extra debugging, and will log each lvar found in the scan. The log file may get quite large, depending on how long t takes to crash... John layout.json FSUIPC7_WASM.wasm

Well, I can't even reproduce when NOT debugging! Yes, looks to be crashing on the same place. I will add extra logging in this area and provide you a new WASM shortly. This is very strange - I have not seen that error here. Could you let me know what add-ons you are using, and if using GSX maybe try without that, John

Ok, thanks. That is interesting and also very confusing, as it seems to be crashing in a block where there is no possibility of a memory issue, except if it is in the Gauge API function get_name_of_named_variable. Unless maybe there is a buffering issue with the log messages. Very strange... Ok, thanks, although I doubt the log files will reveal anything. Really I need to get this error here and trap it in a debugger, but after many hours of trying I still cannot reproduce....

Yes! My log file was > 64GB after an extended run. There is no way to open such large files - you need to split it into smaller files (when you get a crash) and send me the last 500mb or so. To split the files, see https://stackoverflow.com/questions/31786287/how-to-split-large-text-file-in-windows. It is definitely a memory issue, but I cannot find any memory issues, and I have ran MSFS.FSUIPC7 for over 24 hours with the WASM attached to a debugger, switching aircraft many times and sending many presets and lvar updates without issues. So this is very strange. It could be that another add-on is trashing an lvar name string that I am referencing, and when I try to reference this it causes the error. I have changed some code in the attached WASM version to correct for this if you could try it. I have removed the extra logging in this version, so the log files shouldn't be too large and it shouldn't effect the performance that much, so please switch to this version and let me know how you get on. Thanks for your assistance with this issue. John FSUIPC7_WASM.wasm layout.json

Could you please try with the attached WASM module and let me know how it goes. Thanks, John layout.json FSUIPC7_WASM.wasm

Please show me/attach your FSUIPC7.log and FSUIPC7.ini files.

Try the presets PMDG B777 FUEL CONTROL LEVER R CUTOFF and PMDG B777 FUEL CONTROL LEVER R CUTOFF, or the presets PMDG 777 FUEL CUT OFF ENGINE 1 TOGGLE and PMDG 777 FUEL CUT OFF ENGINE 2 TOGGLE. If you check Select for Preset and then click the Find Preset... button, they will be listed under MobiFlight -> PMDG -> B777 300ER ->Engine. John

I spoke to soon...someone lese has now just reported an issue which also looks like a WASM crash. I will keep investigating. If you could provide me with the last few thousand lines of the log file generated by the last version I posted then that would be useful. However, you should only use that version until you can generate the log file for me, then switch back to the released or tagged-data version. The log file from my last session trying to reproduce this grew to more than 64GB!

Sounds like you are also experiencing a WASM crash. Yes, that is the thread where this was originally reported. Was the FSUIPC_WASM.log file you attached uploaded after MSFS was shut-down? If so, it was definitely a WASM crash. If not, the next time this occurs can you exit MSFS and take a look at the end of the FSUIPC_WASM.log file. If the log file ends with the WASM closing down like this: then there was no crash, but if it didn't log that message then it looks like the WASM crashed. You can also open the MSFS logging console (only available once devmode is activated) and search for 'messages with 'fsuipc' in them - if the FSUIPC WASM crashed there should be a message to this effect. I have been investigating this issue for over a week now and cannot reproduce this here. I will keep investigating this and get back to you.

Ok, glad its all now working again. I am not sure what fixed this though - re-installing really should not fix anything as there are only the two exe's that do anything, unless one of them got corrupted somehow...

You shouldn't need to restart the PC after installation, and yes - you open the FSUIPC6 main window from the P3D Add-ons menu, John

I am starting to think that this is not an issue in the WASM itself, but in your installation. However, I thought WASMs were self-contained (in a sand-box), so its rather strange. Anyway, I have added more logging in the attached if you could try this. The WASM log file will be very large - you may need to use a file transfer service to show it to me, if too large to attach when compressed. I will continue trying to reproduce here, but so far I cannot get the WASM to crash, and I am using he same aircraft (FBW A320, PMDG 777 and 737) and more. It maybe worth validating your MSFS installation. In Steam, you would do this from the game properties and selecting 'Verify intergity of game files', but I don't know how to do this in the MS Store version. John layout.json FSUIPC7_WASM.wasm Note: using this version will generate a huge log file, and the size will be dependent on how long the WASM runs before it crashes. It will probably also slow down MSFS quite a bit due to this excessive logging. I have been running this version for several hours now, switching planes and using plenty of presets and I still cannot provoke a WASM crash. Anyway, if you can try this version and can provoke a crash I will take a look. As the log file will be huge, even compressed, probably better to use a large file transfer service (with compressed file), such as https://filetransfer.io/. I have spent quite a lot of time on this issue now, and cannot reproduce here so I do think that this is peculiar to your system. And if there was a memory issue in the WASM I would have expected this to be reported by other users, which they haven't. So it may be worth checking your installation, as advised above, or maybe verifying your add-ons with Parallel 42's Simstaller (see https://parallel42.com/products/simstaller). Plenty of info on this product via google. Sorry, but I am running out of ideas on this one, and I need to get on to other issues....although I will check your log file from this latest update when provided.

Your logs show that WideServer/FSUIPC is not receiving the response from WideClient and the connection times-out: This error is usually caused by the connection being blocked by a firewall. Are you sure that you tested with ALL firewalls turned off? Especially check the firewall(s) on your server PC (i.e. the one running MSFS/FSUIPC7). Alternatively, something else could be running on the default ports (8002 and 9002). You could try changing these (for both WideServer and WideClient) - see the WidFS Technical guide for details on the Port and Port2 ini file oprions. Note that your FSUIPC7.log is large as you have event and axis controls activated, which aren't needed. Anyway, I just wanted to check that WideServer was running, which your logs show, so no need to attach that file again. There are quite a few reports with this same error/issue over the years (Flight Sim version not really important for this issue as WideServer and WideClient will be the same), and it is always the firewall configuration (maybe caused by a windows update) that causes this issue. For example, see the following: John

@JARS I know this post is now 6 years old now, but do you remember what exception and where this is located in P3D? Or do you mean that you ticket the box in a router config page to allow P3D to send/receive external traffic?

@Javinet Why are you posting the same question again in the wrong sub-forum. I have moved your 2nd post in the FAQ sub-forum. I will not do this again - they will just be deleted. Please see my original comment and follow instructions there if you want support for this issue. John

Please exit FSUIPC7 and WideClient before attaching files (you can keep MSFS running). If its too large, compress/zip it. WideClient again looked like it connected: But there was no sign of it in your WideServer.log file though. I will check things here when I get a chance and get back to you. However, it would be useful to see all the correct files from the same session, and attached when FSUIPC7 / WideClient have closed. You also seem to be using a very old version of FSUIPC7 (including WideServer) - 7.2.11, which is from October 2021. I am very surprised that version even works... And I only support the latest version, which is 7.4.15. Can you please update to the latest version of FSUIPC, try again, and remember to exit FSUIPC7 and WideClient before attaching files. John

Your FSUIPC7.1.log is a continuation log file. Please do not do this (i.e. start a new log) - I need to see the full log file not a partial one. And your WideClient.log shows that it connected but that you closed WideClient after 7 seconds: Why was this? Can you explain what happened please, or try running WideCLient for a bit longer...

Please also attach the WideServer.log file.

First, you posted in the FAQ sub-forum where it explicitly states NOT for support requests. I have moved your post to the main support forum, Please use this forum for all issues with FSUIPC6. Then please show me/attach your InstallFSUIPC6.log file. This implies that you are trying to install under the Documents\Prepar3D v5 Add-ons folder. You should use this location for the add-on.xml file only. When you install, please choose another folder, and not under a windows protected folder (such as Documents or Program Files). Select a non-windows protected folder, such as c:\FSUIPC6 or C:\P3Dv5 Add-ons\FSUIPC6. If you still get issues when installing in a non-windows protected folder, show me/attach your InstallFSUIPC6.log file. John

@Edoradar Sorry for the delay with this -I have been rather busy with MSFS / FSUIPC7 (as usual!) and also suffering from lower back and sciatica issues which are restricting the amount of time I can remain seated and working... Anyway, please try the attached dll, beta version v6.2.1c. I have enable writing at offset 0x3402 but only for bits 0,1, 4,5,6 & 7. So, to assign to a button/key press, you need to assign to the control Offset Word Togglebits with parameters: 0x1 - to toggle pause 0x2 - to toggle slew mode 0x10 - to toggle position freeze 0x20 - to toggle attitude freeze 0x40 - to toggle altitude freeze 0x80 - to toggle lat/long freeze Please test this and let me know how you get on. Once this is tested and I have updated the documentation I will release this version. Cheers, John FSUIPC6.dll

This is very strange... again, the log files show nothing. Can you use the attached please - I have added a couple of more debug log statements to try and track down where this crash is happening. The log file will be a lot larger and may need zipping, but still al lot smaller than trace logging. layout.json FSUIPC7_WASM.wasm

Very strange...did anything change? It is in the WASM persistence storage area - from the Advanced User guide: John

@BJHawk Could you please try the attached updated WASM module please. Save the FSUIPC7_WASM.wasm file to your Community\fsuipc-lvar-module\modules folder, and the layout.json and manifest.json files to your Community\fsuipc-lvar-module folder. There is not a specific fix for this issue, but I have switched to using tagged data so this version should be more efficient. Let me know if you have any issues, and if so please attach your FSUIPC_WASM.log file. @J-Aviator If your issue is with a WASM crash, please also try this version. John manifest.json layout.json FSUIPC7_WASM.wasm

This issue is related to an FSUIPC CTD has now been reported in the following topic: For users with the issue that FSUIPC is running but not opening/displaying when instructed (e.g. on keypress Alt+F), then this is usually because the window is being sized/positioned off-screen. To rectify this, you need to exit FSUIPC and delete the Window ini parameter from the [General] section of your FSUIPC7.ini file and then restart FSUIPC7. This will reset FSUIPC to the default size and position. John

@DaveSCUSA Are you still having this issue?