Application crashes when using WASM Module

[Fragtality]

Hi!

I'm currently integrating the WASM Module in my StreamDeck Plugin/PilotsDeck via Paul's C# Client and it works great so far.

But only if FSUIPC7 or my Plugin are not restarted when a Plane/Flight is loaded (no Problem in the Main Menu). When I restart my Plugin it will crash with a "Access Violation". When I exit FSUIPC the Plugin will load but FSUIPC7 will crash when I try to start it again.
From what I can tell it happens when the WASM Module tries to load/setup the Lvars, because the last line I receive in my Plugin is "EVENT_LVARS_RECEIVED" (FSUIPC running, StreamDeck/Plugin restarted). The other way around (StreamDeck/Plugin running and FSUIPC restarted) the last line in the FSUIPC7.log is "Connected to MFSFS".

[John Dowson]

First, can you download and try with the latest FSUIPC7 release, v7.3.5, released earlier today. The WASM & WAPI have also both been updated to 0.5.9 in this release, so you will also have to recompile your plugin with the latest version.

Once that is done, if you still experience the same issue, can you activate Debug level logging in both the WAPI and the WASM and show me both your FSUIPC7.log and FSUIPC_WASM.log files. A WAPI log file from your StreamDeck plugin would also be useful, if you could also generate that with Debug level logging. I think your issue may be to do with having multiple WASM clients...

John

[Fragtality]

Same Behavior with 7.3.5/0.5.9 😕

I've started MSFS/FSUIPC without the Plugin running and started it after the Flight was loaded.

I hope the FSUIPC and WASM Logs are as expected?
I've changed LogLevel to Debug in the FSUIPC_WASM.ini and added that to the FSUIPC7.ini:
[WAPI]
EnableWAPI=Yes
LogLevel=Debug

 

FSUIPC7.log PilotsDeck.log FSUIPC_WASM.log

[John Dowson]

But those logs show that FSUIPC7 ran as expected and exited as MSFS was no longer running. Also no WAPI Debug level logging is present in the FSUIPC7.log (although it is in your PilotDeck.log) - are you sure you enabled it?

2 hours ago, Fragtality said:

I've started MSFS/FSUIPC without the Plugin running and started it after the Flight was loaded.

Maybe have your plugin running, so that FSUIPC7 crashes and I can see the log from that. I cannot help debug a crash in your application.
 

[Fragtality]

6 minutes ago, John Dowson said:

But those logs show that FSUIPC7 ran as expected and exited as MSFS was no longer running. Also no WAPI Debug level logging is present in the FSUIPC7.log (although it is in your PilotDeck.log) - are you sure you enabled it?

Maybe have your plugin running, so that FSUIPC7 crashes and I can see the log from that. I cannot help debug a crash in your application.
 

Yeah it was only the Test-Case that FSUIPC7 keeps running and the Plugin is restarted - you didn't mention wich one you prefer^^
I surely added something to the FSUIPC7.ini to enable it (see my previous Post), but I'm not sure if that enabled it xD 

Here the Logs when FSUIPC7 crashes! Steps:
- Loaded MSFS via the FSUIPC Shortcut (Plugin is running)
- Loaded a Flight
- Stopped FSUIPC7
- Started FSUIPC7 => Crashed

FSUIPC_WASM.log FSUIPC7.log PilotsDeck.log

[John Dowson]

The FSUIPC7.log doesn't show anything...can you change the log-level to Trace and repeat please. Maybe also activate Event logging in FSUIPC7.
The WASM log shows that something, probably your plugin, is configured to send lvar update requests to the WASM:
 

Quote

...
Sat May 28 18:10:08 2022   [ERROR]: Ignoring request to update LVARs as updated internally
Sat May 28 18:10:08 2022   [ERROR]: Ignoring request to update LVARs as updated internally
Sat May 28 18:10:08 2022   [ERROR]: Ignoring request to update LVARs as updated internally
Sat May 28 18:10:08 2022   [ERROR]: Ignoring request to update LVARs as updated internally
Sat May 28 18:10:08 2022   [ERROR]: Ignoring request to update LVARs as updated internally
...

This won't be the cause of the crash, but you should disable this and leave the lvar update period to the WASM (you can change this period if you like).

Show me the updated logs. Finishing now - I may take a look tomorrow morning if I get time, but most probably be Monday.

[Fragtality]

11 minutes ago, John Dowson said:

The FSUIPC7.log doesn't show anything...can you change the log-level to Trace and repeat please. Maybe also activate Event logging in FSUIPC7.

Of course it does not show anything ... FSUIPC crashed, that is the Test-Case you requested ^^
It is a very hard crash - even the catch-Block in my Plugin is not able to catch any exception that would help 😕 Got the information about the "Access Violation" from the Debug Output from VS (debugging my Plugin). The Debugger itself also just stops and is not able to show the location.

Please provide me with the exact Settings you want me to set in the FSUIPC7.ini - I did like I described in my Post earlier and that was described as per Advanced User Guide. But either that is not want you wanted or I configured it wrong.

 

22 minutes ago, John Dowson said:

This won't be the cause of the crash, but you should disable this and leave the lvar update period to the WASM (you can change this period if you like).

Uhm ... I don't know what you mean, I'm not aware that I enabled something like that in the first place 😮
I'm just starting it (IPCManager.cs#L73) and checking the IsRunning State (IPCManager.cs#L29).
Only after WASM is ready (that is after VariableListChanged Event received) the Lvars are read (IPCManager.cs#L267  --> IPCValueWASM.cs#L18 - for every unique Lvar the User has configured and currently visible on the Deck)

 

46 minutes ago, John Dowson said:

Show me the updated logs. Finishing now - I may take a look tomorrow morning if I get time, but most probably be Monday.

Here the Logs 🙂
Whenever you have time - it's no showstopper for normal usage and for developing the loading of new flight thankfully does not take that long in msfs (compared to p3d^^)

logexport.zip

[Fragtality]

Some Updates:

- It seems to be dependent on which plane is loaded. I accidentally choose the FBW32N and FSUIPC7 did not crash (twice).
- With the Default 747 I tested all the time it crashed again.
- Found the Reason for the missing Messages in the FSUIPC7.log: I've added a second [WAPI] Section -.- Sorry!
- Although I now forgot to re-enable Event-Logging. Will redo later ^^
- But: FSUIPC7 crashes at the same Point like my Plugin: after the "EVENT_LVARS_RECEIVED" Log-Message is received.
- Compressed with 7-Zip, else it would be to big

logexport-crashed.7z logexport-working.7z

[John Dowson]

1 hour ago, Fragtality said:

- Found the Reason for the missing Messages in the FSUIPC7.log: I've added a second [WAPI] Section -.- Sorry!

Not sure what you mean by 'second [WAPI] Section' - there should only be one....! But thank you - I can finally see the messages from the WAPI that I was looking for...
This narrows it down to around 10 lines of code, which look ok...I will investigate further tomorrow, but I think I will need to provide you with a special build to track this down further...it is crashing somewhere between the LOG_DEBUG and the LOG_TRACE statements in this section of the code:

           sprintf_s(szLogBuffer, sizeof(szLogBuffer), "EVENT_LVARS_RECEIVED: dwObjectID=%d, dwDefineID=%d, dwDefineCount=%d, dwentrynumber=%d, dwoutof=%d",
					pObjData->dwObjectID, pObjData->dwDefineID, pObjData->dwDefineCount, pObjData->dwentrynumber, pObjData->dwoutof);
			LOG_DEBUG(szLogBuffer);
			noLvarCDAsReceived++;
			CDAName* lvars = (CDAName*)&(pObjData->dwData);
			// Find id of CDA
			int cdaId = 0;
			for (cdaId = 0; cdaId < MAX_NO_LVAR_CDAS; cdaId++)
			{
				if (lvar_cdas[cdaId]->getDefinitionId() == pObjData->dwDefineID) break;
			}
			if (cdaId < noLvarCDAs)
			{
				for (int i = 0; i < lvar_cdas[cdaId]->getNoItems(); i++)
				{
					sprintf_s(szLogBuffer, sizeof(szLogBuffer), "LVAR Data: name='%s'", lvars[i].name);
					LOG_TRACE(szLogBuffer);

Its also strange that this only occurs when you have a 2nd WAPI client running. I will test with multiple WAPI clients tomorrow and see if I can reproduce...although that section of code should be independent on clients used....

 

20 hours ago, Fragtality said:

21 hours ago, John Dowson said:

This won't be the cause of the crash, but you should disable this and leave the lvar update period to the WASM (you can change this period if you like).

Uhm ... I don't know what you mean, I'm not aware that I enabled something like that in the first place 😮
I'm just starting it (IPCManager.cs#L73) and checking the IsRunning State (IPCManager.cs#L29).
Only after WASM is ready (that is after VariableListChanged Event received) the Lvars are read (IPCManager.cs#L267  --> IPCValueWASM.cs#L18 - for every unique Lvar the User has configured and currently visible on the Deck)

Update frequency of lvars CAN be set by the client, using the LvarUpdateFrequency ini parameter, I'm not sure how thus is used/set using Paul's dll, but it should certainly be possible to set this to 0 (i.e. no update - let the  WASM control this), which should be the default. As your plugin is requesting updates, this has been changed to a non-zero value. Find out where that is, and change or remove it. Ask on Paul's dll forum if not sure.

 

[John Dowson]

Note also that the WAPI is open source (see https://github.com/jldowson/FSUIPC_WAPI) and a debug version of the library is available. It may be easier if you can try and track this down in your plug-un/client (unless I can reproduce). Try with the debug enabled lib to se if you get any more information...

John

[John Dowson]

Checking the logs further, it seems that the config update request from the 2nd client is being picked-up by the first client and is being re-mapped, causing issues:

Quote

    15125  [TRACE]: SIMCONNECT_RECV_ID_CLIENT_DATA received: EVENT_CONFIG_RECEIVED
    15125  [DEBUG]: Config Data 0: name=FSUIPC_VNAME7, size=8176, type=0
    15125  [DEBUG]: Config Data 1: name=FSUIPC_VNAME8, size=8176, type=0
    15125  [DEBUG]: Config Data 2: name=FSUIPC_VNAME9, size=8176, type=0
    15125  [DEBUG]: Config Data 3: name=FSUIPC_VNAME10, size=8176, type=0
    15125  [DEBUG]: Config Data 4: name=FSUIPC_VNAME11, size=7952, type=0
    15125  [DEBUG]: Config Data 5: name=FSUIPC_lvalues0, size=8192, type=2
    15125  [DEBUG]: Config Data 6: name=FSUIPC_lvalues1, size=8192, type=2
    15125  [DEBUG]: Config Data 7: name=FSUIPC_lvalues2, size=8192, type=2
    15125  [DEBUG]: CDA name FSUIPC_VNAME7 mapped to ID 4 [requestId=17]
...
    15125  [TRACE]: Config data updates requested.
    15125  [TRACE]: SIMCONNECT_RECV_ID_CLIENT_DATA received: EVENT_CONFIG_RECEIVED
    15125  [DEBUG]: Config Data 0: name=FSUIPC_VNAME7, size=8176, type=0
    15125  [DEBUG]: Config Data 1: name=FSUIPC_VNAME8, size=8176, type=0
    15125  [DEBUG]: Config Data 2: name=FSUIPC_VNAME9, size=8176, type=0
    15125  [DEBUG]: Config Data 3: name=FSUIPC_VNAME10, size=8176, type=0
    15125  [DEBUG]: Config Data 4: name=FSUIPC_VNAME11, size=7952, type=0
    15125  [DEBUG]: Config Data 5: name=FSUIPC_lvalues0, size=8192, type=2
    15125  [DEBUG]: Config Data 6: name=FSUIPC_lvalues1, size=8192, type=2
    15125  [DEBUG]: Config Data 7: name=FSUIPC_lvalues2, size=8192, type=2
    15125  [DEBUG]: CDA name FSUIPC_VNAME7 mapped to ID 12 [requestId=58]

I have enough information to look into this now, and will report back when I find the cause.

Thanks for those logs!

John

[Fragtality]

1 hour ago, John Dowson said:

Not sure what you mean by 'second [WAPI] Section' - there should only be one....!

As simple and dumb as I said - I added another [WAPI] Section at the Bottom of the Ini to enable Logging completely unaware there was already one^^ So only the first was used and the second one was ignored. Typical Problem where the Root-Cause was in front of the Monitor 😄

 

1 hour ago, John Dowson said:

.it is crashing somewhere between the LOG_DEBUG and the LOG_TRACE statements in this section of the code:

1 hour ago, John Dowson said:

Its also strange that this only occurs when you have a 2nd WAPI client running. I will test with multiple WAPI clients tomorrow and see if I can reproduce...although that section of code should be independent on clients used....

Strange thing, for sure! 🤔
I can only do wild and uneducated guesses: Either dwdata, lvar_cdas or lvar_cdas at cdaId causes a Null-Pointer-Exception or the Critical/Mutex Section should also include those lines (because multiple Clients alter the Counter/Index which in turn generates a Null-Pointer/Out-of-Range Exception). *g*

1 hour ago, John Dowson said:

Note also that the WAPI is open source (see https://github.com/jldowson/FSUIPC_WAPI) and a debug version of the library is available. It may be easier if you can try and track this down in your plug-un/client (unless I can reproduce). Try with the debug enabled lib to se if you get any more information...

  I can give it a try, sure! But I'm very unused to C/C++ and especially how I debug a library which is not part of the project 😕

 

1 hour ago, John Dowson said:

Update frequency of lvars CAN be set by the client, using the LvarUpdateFrequency ini parameter, I'm not sure how thus is used/set using Paul's dll, but it should certainly be possible to set this to 0 (i.e. no update - let the  WASM control this), which should be the default. As your plugin is requesting updates, this has been changed to a non-zero value. Find out where that is, and change or remove it. Ask on Paul's dll forum if not sure.

Sure, I'll ask Paul! I do not set the Frequency to leave it at the default, since per his description in the Thread it defaults to 6Hz (the same in the WASM-Config). So I thought the Default is fine for me! Did not want to mess around with the settings 😅
But I can set it explicitively to zero 😉 

 

 

59 minutes ago, John Dowson said:

I have enough information to look into this now, and will report back when I find the cause.

Thanks for those logs!

Great! If you need anything more or any testing with special Builds, just drop me a line 🙂 

 

Thanks &
Cheers
Daniel

[Fragtality]

1 hour ago, Fragtality said:

2 hours ago, John Dowson said:

Note also that the WAPI is open source (see https://github.com/jldowson/FSUIPC_WAPI) and a debug version of the library is available. It may be easier if you can try and track this down in your plug-un/client (unless I can reproduce). Try with the debug enabled lib to se if you get any more information...

  I can give it a try, sure! But I'm very unused to C/C++ and especially how I debug a library which is not part of the project 😕

Nope, I'm to spoiled from C#/.Net -.-

After getting it finally somehow compiled, the Plugin is crashing now because "Unable to find an entry point named 'fsuipcw_isRunning' in DLL 'FSUIPC_WAPID.dll'. " 😕 
Which is true - none of the source-File would contain such a function. I'm missing some kind of Info/Step here which I can't figure out myself.
I wanted to give it a try with a quick & dirty try/catch Block and (and write the Exception to the log) around that specific area if that would yield any info.

[John Dowson]

I understand what is happening now - the fix is relatively simple. I will post you a version to try later today.
 

[John Dowson]

@Fragtality Could you try the attached version please. I've also attached the updated WAPI library (and header - not sure if you need this) for you to  use to rebuild your client (zipped).

Let me know how it goes - attach the trace logs again if any issues.

Thanks,

John

FSUIPC7.exe  FSUIPC_WAPI.zip 

[Fragtality]

YEP! That works 😃

I can restart either FSUIPC or my Plugin and neither Crashes anymore!
Although I only replaced the FSUIPC7 Executable - don't know where I would need the static Libraries. Since my Plugin is C#, I use Paul's C# Client which in Turn uses the dynamic WAPI Library (FSUIPC_WAPID.dll from the Utils-Directory).

In addition my Plugin now sets the UpdateFrequency to 0 (but I've tested that before the Special-Build, that was not the Issue).

Many thanks!!! 🙂

[John Dowson]

20 minutes ago, Fragtality said:

Although I only replaced the FSUIPC7 Executable - don't know where I would need the static Libraries. Since my Plugin is C#, I use Paul's C# Client which in Turn uses the dynamic WAPI Library (FSUIPC_WAPID.dll from the Utils-Directory).

I have also updated the dll - please find attached.FSUIPC_WAPID.dll

I will release this version shortly.

Thanks got your help with this.

John

 

[Fragtality]

Uhm ... can it be that the Textfile/List with all the Standard Controls is missing is this release?

Just reinstalled 7.3.6 again and it doesn't appear (all the PDFs are there though).

[John Dowson]

58 minutes ago, Fragtality said:

Uhm ... can it be that the Textfile/List with all the Standard Controls is missing is this release?

Just reinstalled 7.3.6 again and it doesn't appear (all the PDFs are there though)

That file is deleted when you uninstall, and will be created (in-the-fly) the next time you run MSFS. It is automatically generated once connected to MSFS.

John

[Fragtality]

🤦‍♂️ 🤦‍♂️ 🤦‍♂️

 

Thanks 😅