Button&Switches Presets stop working

[J-Aviator]

As far as I can tell and from best of knowledge, I don't change anything, just load the sim and run the plain to check.
I'll do I flight this evening and let you know if any other issue is come up. 

 

Thanks for the tip to find the location of FSUIPC_WASM.ini log file.

[BJHawk]

9 hours ago, John Dowson said:

... not been able to get the WASM to crash/fail.

Just like at my work, I can crash WinME PC in a way even developers of our systems thought impossible 😅

Tried the updated WASM. FBW behaved for a while so I switched to PMDG 777, it worked so i messed about and at some point it stopped working again. Exited FSUIPC as soon I noticed it.

EDIT: At around the same time WASM crashed MSFS console produced this error:

WASM: Exception c0000005 in SimConnect DispatchProc in module vfs://fsuipc-lvar-module/modules/FSUIPC7_WASM.wasm

FSUIPC7.log FSUIPC_WASM.log

[John Dowson]

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

[BJHawk]

 

Crash. Had the console opened and watching FSUIPC errors. Once again, started with FBW, that worked fine, switched to PMDG 777, the second I touched a button WASM crashed - line 2383 of FSUIPC7_prev.log, might be a coincidence. Did a second test going 777 > FBW, crash as well, without me even touching any button (the end of FSUIPC log is me confirming what I saw in the console).

WASM: Exception c0000005 in SimConnect DispatchProc in module vfs://fsuipc-lvar-module/modules/FSUIPC7_WASM.wasm

FSUIPC7_prev.log FSUIPC7.log FSUIPC_WASM_prev.log FSUIPC_WASM.log

[John Dowson]

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.

[John Dowson]

21 hours ago, John Dowson said:

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.

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!

 

 

[BJHawk]

Uh, yeah, when you said "really large" i thought you might be exaggerating a bit, it will be like 50MB. Holly, how wrong I was 😅 Less than an hour and it's almost 2GB! Had to find an app that can open it! And it really did slow the sim noticeably, didn't expect that either.

I tried it yesterday, and no crash. Went FBW>777>FBW just fine. That's something I've noticed last time as well, the first launch after replacing the FSUIPC7_WASM.wasm everything works fine.

Will report back today after another try. Will also try using combination of different airports and aircraft, if it is memory crash. Which it feels like it might be, considering I'm switching between two very complex aircraft on massive 3rd party scenery all around me on quite high details. And that is something highly discouraged ever since the times of FS2004!

[John Dowson]

1 hour ago, BJHawk said:

Uh, yeah, when you said "really large" i thought you might be exaggerating a bit, it will be like 50MB. Holly, how wrong I was 😅 Less than an hour and it's almost 2GB! Had to find an app that can open it! And it really did slow the sim noticeably, didn't expect that either.

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.

1 hour ago, BJHawk said:

Will report back today after another try. Will also try using combination of different airports and aircraft, if it is memory crash. Which it feels like it might be, considering I'm switching between two very complex aircraft on massive 3rd party scenery all around me on quite high details. And that is something highly discouraged ever since the times of FS2004!

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

[BJHawk]

Just as I thought, second launch and it crashed shortly after the FBW>777 switch. Here are the few last lines of the log.

Fri Jul 19 14:00:23 2024   [DEBUG]: Values Client Data Area 'FSUIPC_lvalues0' (id=4, definitionId=6) updated (1024 items) at 1721397623505 [requestID=10215]
Fri Jul 19 14:00:23 2024   [DEBUG]: Values Client Data Area 'FSUIPC_lvalues1' (id=5, definitionId=7) updated (1024 items) at 1721397623505 [requestID=10216]
Fri Jul 19 14:00:23 2024   [DEBUG]: Values Client Data Area 'FSUIPC_lvalues2' (id=6, definitionId=8) updated (1024 items) at 1721397623505 [requestID=10217]
Fri Jul 19 14:00:23 2024   [DEBUG]: Values Client Data Area 'FSUIPC_lvalues3' (id=7, definitionId=134) updated (1024 items) at 1721397623505 [requestID=10218]
Fri Jul 19 14:00:23 2024   [DEBUG]: Values Client Data Area 'FSUIPC_lvalues4' (id=8, definitionId=135) updated (1024 items) at 1721397623505 [requestID=10219]
Fri Jul 19 14:00:23 2024   [DEBUG]: Values Client Data Area 'FSUIPC_lvalues5' (id=9, definitionId=136) updated (1024 items) at 1721397623505 [requestID=10220]
Fri Jul 19 14:00:23 2024   [DEBUG]: MyDispatchProc: finished processing event - dwID = 4
Fri Jul 19 14:00:23 2024   [DEBUG]: MyDispatchProc: event received - dwID = 4
Fri Jul 19 14:00:23 2024   [DEBUG]: MyDispatchProc: ID_EVENT request - uEventID = 4
Fri Jul 19 14:00:23 2024   [DEBUG]: Scanning for new lvars: lvarScanFrequency=-5, last lvarScanTime=1721397618712, timeNow=1721397623716 (difference=5004)

Entire log is here: https://filetransfer.io/data-package/EvBiytnz#link

Last ALMOST 2 SECONDS! are attached

Found that the program GLOGG is able to  open large logs, not sure of the limits though 😅

Will report back shortly with the logs from the wasm you just uploaded. My guess would be an addon, but then it wouldn't be random for me, I use the same all the time. I'm only switching planes to force the crash semi-reliably

EDIT: Also not sure, might be something to look at, but every single time any plane loads I get this error in Console:

[Coherent GT] Failed to locate file vfs:///Flow/templates/fsuipc-lvar-module.json

New Text Document (4).txt

[John Dowson]

1 minute ago, BJHawk said:

Just as I thought, second launch and it crashed shortly after the FBW>777 switch. Here are the few last lines of the log.

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...

16 minutes ago, BJHawk said:

Will report back shortly with the logs from the wasm you just uploaded.

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....

[BJHawk]

This time it crashed on the first launch shortly after the FBW>777 switch 🤷‍♂️. I know how you feel, felt the same many times at work. The worst faults are the ones that are not happening when debugging.

Can see it crashed with the same last log entry. I've also attached the FSUIPC log from the previous crash. The ending seems the same

FSUIPC_WASM.log FSUIPC7.log FSUIPC7_prev.log

[John Dowson]

3 minutes ago, BJHawk said:

The worst faults are the ones that are not happening when debugging.

Well, I can't even reproduce when NOT debugging!

4 minutes ago, BJHawk said:

Can see it crashed with the same last log entry. I've also attached the FSUIPC log from the previous crash. The ending seems the same

Yes, looks to be crashing on the same place. I will add extra logging in this area and provide you a new WASM shortly.

39 minutes ago, BJHawk said:

EDIT: Also not sure, might be something to look at, but every single time any plane loads I get this error in Console:

[Coherent GT] Failed to locate file vfs:///Flow/templates/fsuipc-lvar-module.json

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

[John Dowson]

Quote

[Coherent GT] Failed to locate file vfs:///Flow/templates/fsuipc-lvar-module.json

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

[BJHawk]

Yes, I am always replacing both files, both in the Community WASM folder.

Another test done (with previous WASM), tried different sceneries this time, all without the sim reload. For the testing I'm using all the same active addons, sceneries and settings to mitigate as much inconsistency as possible.

Went FBW>777 on TailStrike LKPR, pretty easy scenery, all fine. Then went to virtuFRA EDDF in the same 777, which is a really demanding scenery, barely got above 10FPS, all fine. Then went to iniBuilds EGLL in the same 777, demanding scenery but about 20FPS, it crashed shortly. In all the tests I power up the plane and use GSX to connect the jetway, then just laze about, looking around at the scenery.

Since it seems to be memory and thus system problem, I've attached my MSFS UserCfg. I'm running Dual 4K monitor Windows 11 on an ASUS TUF Gaming Z790-PLUS WIFI with Intel i7-14700KF, G.SKILL 2x32GB DDR5 6000MHz Trident Z5 RAM and  MSI GeForce RTX 4060 Ti VENTUS 2X BLACK 16G OC. Not the best, but pretty beafy.

EDIT: My addon list is possibly way too long 😅. Program wise, it's always running FSLTL, FBW SimBridge, MSFS Map Enhancement, RealTurb CAT, Navigraph Simlink, AIFlow, AIGround, GSX, FSRealistic, all run by MSFS Addon Linker. Rest is in my attached exe.xml

FSUIPC7.log FSUIPC_WASM.log UserCfg.opt EXE.xml

[John Dowson]

9 minutes ago, BJHawk said:

Another test done (with previous WASM), tried different sceneries this time, all without the sim reload. For the testing I'm using all the same active addons, sceneries and settings to mitigate as much inconsistency as possible.

Went FBW>777 on TailStrike LKPR, pretty easy scenery, all fine. Then went to virtuFRA EDDF in the same 777, which is a really demanding scenery, barely got above 10FPS, all fine. Then went to iniBuilds EGLL in the same 777, demanding scenery but about 20FPS, it crashed shortly. In all the tests I power up the plane and use GSX to connect the jetway, then just laze about, looking around at the scenery.

Ok, but this doesn't really help as the log shows the WASM crashing after the same line is logged.

10 minutes ago, BJHawk said:

Since it seems to be memory and thus system problem, I've attached my MSFS UserCfg. I'm running Dual 4K monitor Windows 11 on an ASUS TUF Gaming Z790-PLUS WIFI with Intel i7-14700KF, G.SKILL 2x32GB DDR5 6000MHz Trident Z5 RAM and  MSI GeForce RTX 4060 Ti VENTUS 2X BLACK 16G OC.

This is not relevant to this issue. It is a heap or stack corruption, which is (or should be) only available to the WASM.

10 minutes ago, BJHawk said:

In all the tests I power up the plane and use GSX to connect the jetway, then just laze about, looking around at the scenery.

Ah, GSX....this has caused issues before. If you can first try with the latest WASM and show me the log (after a crash) from that, hopefully that will be more useful.
Once you have done that, maybe try without GSX for a while to see if it still crashes without that...

John

[BJHawk]

GSX is not the culprit, have it actually uninstalled. With GSX is the _prev log.

With GSX it crashed on my usual test. Without it it crashed after reloading the flight at different airport. Did another test with a bunch of addons disabled, crashed again. Will continue down the rabbit hole on my own on Sunday till I'm running Vanilla

FSUIPC_WASM.rar FSUIPC_WASM_prev.rar FSUIPC7.rar

[John Dowson]

Those logs are interesting, and show that the WASM is most probably crashing when calling an MSFS Gauge API function  get_name_of_named_variable. Although it could be crashing when I am logging the name returned by this function, but that was a recent addition so I doubt it. I have added additional code in the attached WASM to correct for this, so please switch to this version. Not sure what, if anything, I can do if its crashing in that function, except report to Asobo.

I don't this error is actually anything to do with FSUIPC but something else causing a memory issue in MSFS that is causing the WASM to crash....

Anyway, last update doe today. I will continue investigating over the weekend, when I have time.

John

layout.json

FSUIPC7_WASM.wasm

[John Dowson]

1 hour ago, BJHawk said:

GSX is not the culprit, have it actually uninstalled. With GSX is the _prev log.

Ok... 

1 hour ago, BJHawk said:

Did another test with a bunch of addons disabled, crashed again. Will continue down the rabbit hole on my own on Sunday till I'm running Vanilla

What add-ons are you actually using (apart from scenery and aircraft)? Maybe best to just start with FSUIPC installed, test that, and then add each add-on back one by one until you get the crash, Then go back and change the order to confirm its one add-on (could be a combination of add-ons....).

You can also try the Simstaller program, which I think I mentioned earlier, to see if there are any conflicts. I have not used this yet myself although its been on my list to try for quite a while...

 

[BJHawk]

I did a few more test with previous WASM, and did "clean" launch with just a handfull of addons and FSUIPC, it was fine. Can't remember the last time MSFS was running so well...

So far I've ruled out Aerosoft VDGS, FlightControlReplay, FBW, Fenix, FS2Crew, FSLTL, Headwind A330, HorizonSim 787, HungaryVFR, Sky4Sim, IniBuilds A300, Navigraph, P42 Flow with SimFX (although it was causing the aforemention error of file not found), PMDG 777, PMS GTN, virtuFRA EDDF. These are addons not managed by Addon Linker and it works with them. Plus GSX, some lighting addons, LVFR, CaptainSim, Carenado, Salty 747.

Did try the Simstaller and it didn't produce any unexpected warnings, all from addons I have had installed for years.

Will continue on Sunday and report back.

[John Dowson]

12 hours ago, BJHawk said:

So far I've ruled out Aerosoft VDGS, FlightControlReplay, FBW, Fenix, FS2Crew, FSLTL, Headwind A330, HorizonSim 787, HungaryVFR, Sky4Sim, IniBuilds A300, Navigraph, P42 Flow with SimFX (although it was causing the aforemention error of file not found), PMDG 777, PMS GTN, virtuFRA EDDF. These are addons not managed by Addon Linker and it works with them. Plus GSX, some lighting addons, LVFR, CaptainSim, Carenado, Salty 747.

You should be ok with all aircraft and scenery add-ons (although you can test with all these installed first to confirm) I would think, it is the other add-on types I would concentrate on, and add those back one at a time. It is interesting that MSFS console error of file-not-found is caused by Flow/SimFX - I wonder why this is, but I doubt very much that this is anything to worry about.

12 hours ago, BJHawk said:

Did try the Simstaller and it didn't produce any unexpected warnings, all from addons I have had installed for years.

Ok, that's good.

12 hours ago, BJHawk said:

Will continue on Sunday and report back.

Ok, sounds good - thanks. It would be very useful to know which add-on or combination of add-ons provoke this issue. I don't think its worth me continuing to try and reproduce this issue here at the moment.

I am also going to post on the Asobo support forums about this issue. I will also release a new version of FSUIPC7 with the latest WASM updates in the next few days.

Regards,

John

[BJHawk]

Hi John,

I have some news! One good news and one bad news. The good news is I have I think isolated the issue. The bad news is ... it's not caused by any program, asset, or aircraft, but against all odds by demanding sceneries.

I have been able to jump around the world, and switch between FBW and PMDG just fine (almost) as long as I don't use detailed sceneries. I had a few CTD's, but my guess it's just MSFS and all the addons not sure what to do anymore with me jumping from plane to plane and airport to airport without restarting the sim.

Why is it crashing though is still a mystery, as sometimes with sceneries it does sometimes it doesn't. Possibly also depending on other programs running on the PC eating away system power.

At this point I'll just leave it be, since I've been forcing it to crash, and will report if I encounter any WASM crash in the wild.

[John Dowson]

5 minutes ago, BJHawk said:

I have some news! One good news and one bad news. The good news is I have I think isolated the issue. The bad news is ... it's not caused by any program, asset, or aircraft, but against all odds by demanding sceneries.

I have been able to jump around the world, and switch between FBW and PMDG just fine (almost) as long as I don't use detailed sceneries. I had a few CTD's, but my guess it's just MSFS and all the addons not sure what to do anymore with me jumping from plane to plane and airport to airport without restarting the sim.

Why is it crashing though is still a mystery, as sometimes with sceneries it does sometimes it doesn't. Possibly also depending on other programs running on the PC eating away system power.

At this point I'll just leave it be, since I've been forcing it to crash, and will report if I encounter any WASM crash in the wild.

Ok, that is interesting, and I am very surprised that this is a scenery issue (I don't have much add-on scenery, only a few airports). I will add this information when I report to Asobo, later today or tomorrow.

I will release the updated WASM with a new version of FSUIPC7 in the next few days.

Thanks for your extensive testing for this issue.

Regards,

John

[John Dowson]

Are you just using presets, or are you using lvars directly and their values? If not using lvar values (such as for reading, increment or decrement or on events), you could disable the update of lvar values (where this crash is occurring) which may prevent this crash. To do this, set the WASM ini parameter LvarUpdateFrequency to Off. You can also set the LvarScanFrequency WASM ini parameter to 0 to prevent further scans for lvars after the initial scan.

Probably better to try this after the next FSUIPC7 release, as I think there is a minor issue when setting LvarUpdateFrequency to Off in the version you are using (this issue is now corrected). Or I can provide you with an update WASM if you want to try this now.

John

[BJHawk]

Huh, further testing is necessary, but it seems setting the LvarScanFrequency=0 might have actually solved this problem. I'm using all the addons and it didn't crash in the first sure-crash test. My only worry is if it will affect any addons.

[John Dowson]

5 minutes ago, BJHawk said:

Huh, further testing is necessary, but it seems setting the LvarScanFrequency=0 might have actually solved this problem. I'm using all the addons and it didn't crash in the first sure-crash test. My only worry is if it will affect any addons.

This shouldn't affect any add-ons - unless they are using FSUIPC to access lvars and the lvar needed was not picked up in the first scan. The first scan usually detects all lvars for simpler aircraft (using the default delay of 5 seconds), but for complex aircraft quite a few lvars are detected in subsequent scans. If setting LvarScanFrequency=0 - and you are using complex aircraft, you can adjust the delay before the initial lvar scan is performed by increasing the value of the LvarScanDelay ini parameter. The default is 5 (seconds) - maybe try 8 or 10.