Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Evening Paul,

I updated to the WAPID to 1.0 and now when disconnecting my app ( FSUIPCConnection.Close();) from MSFS via click event, my application now crashes.  When reviewing the event log, all I get is faulty application WAPID.dll.  I wonder if I also need to close the wapi connection too?  It also crashes MSFS.  

Posted

Hi,

Which version of my DLL are you using?

The WASM system and the old FSUIPC connection do not interact at all, so I'm not sure that closing the connection is the cause.

Quote

I wonder if I also need to close the wapi connection too?

You should stop the WAPI connection (MSFSVariableServices.Stop()) before you application (and therefore my DLL) gets unloaded. But the WAPI runs independently from the normal FSUIPC Connection and shouldn't be affected by opening/closing it.

I can't test here as I don't have MSFS, but here are some suggestions:

1. Post the details of the event log error. @John Dowson might be able to tell the cause of the crash from that.

2. Enable the full logging (TRACE) in MSFSVariableServices. This might give some clues before it crashes.

3. Try running the MSFSVariableServices Example Application. You'll need to update the FSUIPC_WAPID.dll to the same one you're using, and update my DLL to the latest via NuGet. See if that has any problems. If it's fine, try adding code to open and close the normal FSUIPCConnection.

Paul

Posted

Are you also using the WASM v1.0?
Can you set debug level logging in both the WAPI and the WASM and show me the log files (both WASM and WAPI).

Also make sure that the lvar updates are performed in the WASM, not the WAPI - i.e. set the LvarUpdateFrequency (n the WAPI) to 0, which should be the default.

John

Posted

Paul/John,

As always, I appreciate your assistance.  To better define the issue, the problem surfaced when updated to WAPID 1.0 and FusipcClient.dll 3.3.4.404;  The app connects without issue and MSFSVariableServices works fine.  However, when attempting to close the connection, the app immediately freezes and crashes; after a few attempts, it will also crash MSFS.  Paul, your MSFSVariableSrvices_CS_V1.4 also crashes when attempting to stop MSFSVariableServices.  Rolling back to FSUIPC7 7.6.16 and the previous WAPID resolves the issue, which I have asked my users to do for now.  

 

Click Event Closing FSUIPC

        private void Connect_Click(object sender, EventArgs e)
        {
            try
            {
                if (FSUIPCConnection.IsOpen)
                {
                    try
                    {                        
                        // Connection is open so stop the timer and close the connection
                        this.fltSimTimer.Stop();
                        FSUIPCConnection.Close();
                        ConfigPicBoxes(picBoxConnect, Color.White);
                        if (Classes.FlagMgmt.chkLstThreadActive == true)
                        {
                            Classes.Copilot_CommonChkLstTasks.copilotChkLstFlowThread.Abort();
                        }
                        ConfigureButtons();
                    }
                    catch (Exception) { }
                }

 

Event Logs 

Faulting application name: FSUIPC7.exe, version: 7.3.1.7, time stamp: 0x63f77964
Faulting module name: FSUIPC7.exe, version: 7.3.1.7, time stamp: 0x63f77964
Exception code: 0xc0000005
Fault offset: 0x00000000000f0496
Faulting process id: 0x0x5808
Faulting application start time: 0x0x1D94A030C1CCBCF
Faulting application path: D:\MSFS Utilites\FSUIPC7\FSUIPC7.exe
Faulting module path: D:\MSFS Utilites\FSUIPC7\FSUIPC7.exe
Report Id: 015a8111-c695-49c2-993f-bfd10ae3584f
Faulting package full name: 
Faulting package-relative application ID: 

Faulting application name: FSFO_NEXT.exe, version: 1.2.11.0, time stamp: 0x829e5f1b
Faulting module name: FSUIPC_WAPID.dll, version: 0.0.0.0, time stamp: 0x63f4bd2f
Exception code: 0xc0000005
Fault offset: 0x0000000000003896
Faulting process id: 0x0x6FE4
Faulting application start time: 0x0x1D94A0405F731C2
Faulting application path: C:\Users\kingm\Dropbox\FSFO\FSFO_NEXT\FSFO_NEXT\bin\Release\FSFO_NEXT.exe
Faulting module path: C:\Users\kingm\Dropbox\FSFO\FSFO_NEXT\FSFO_NEXT\bin\Release\FSUIPC_WAPID.dll
Report Id: 70aa165c-3f0c-42d0-a5af-cb32313a2605
Faulting package full name: 
Faulting package-relative application ID: 

Paul

MSFSVariableSrvices_CS_V1.4 also crashes when attempting to stop MSFSVariableServices.  It also crashed MSFS when I clicked STOP

Application: MSFSVariableServices_CSharp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 00007FFA9B6D3896
Stack:

Faulting application name: MSFSVariableServices_CSharp.exe, version: 1.4.0.0, time stamp: 0x9c35aaae
Faulting module name: FSUIPC_WAPID.dll, version: 0.0.0.0, time stamp: 0x63f4bd2f
Exception code: 0xc0000005
Fault offset: 0x0000000000003896
Faulting process id: 0x0x70E4
Faulting application start time: 0x0x1D94A080C75EFA2
Faulting application path: C:\Users\kingm\Desktop\Development\MSFSVariableServices_CS_V1.4\MSFSVariableServices_CSharp\bin\Debug\MSFSVariableServices_CSharp.exe
Faulting module path: C:\Users\kingm\Desktop\Development\MSFSVariableServices_CS_V1.4\MSFSVariableServices_CSharp\bin\Debug\FSUIPC_WAPID.dll
Report Id: 95e7a8cf-b4c6-4e84-bed1-1ac075448fb2
Faulting package full name: 
Faulting package-relative application ID: 

Please let me know how else I can help!!

John

The part in underline is new, is this normal? 

 [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 1.0.0 (WASM version 1.0.0) using connection -1

FSUIPC7.log

Posted

Maybe @Paul Henty can recompile a new dll against the latest/released WAPID.dll to make sure there is no issue with that. I did make some minor changes between the beta and final release, although I would have thought that this shouldn't matter if the latest WAPID.dll is dynamically loaded, but Paul will know more about this than me....

John

Posted

The WAPID.dll is dynamically loaded so the compiler can't check it. I have just gone through each function and checked all the signatures (and callback signatures) manually and everything is okay. According to GitHub the .h file hasn't changed for 5 months.

There's obviously something behaving differently in the latest WAPID/WASMIF that's causing some issues directly, or causing my use of the WAPID.DLL to be a problem now.

King: What version of the FSUIPC_WAPID.DLL were you using before?

I think the next step would be to get the logs that John asked for to see if those can shed any light on this.

Paul

Posted

Hey Paul,

I was using WAPID 0.9; what's odd is everything works fine until calling  MSFSVariableServices.Stop() and/or FSUIPCConnection.Close(), both seem to generate the crash.  

Where can I find the logs? The only relative logs I see is the FSUIPC7.log, which I provided above.  I don't see any other logs (except for install and uninstall log) in my FSUIPC7 directory, or in the MSFS Community folder.  

Posted
13 hours ago, kingm56 said:

The only relative logs I see is the FSUIPC7.log, which I provided above.

Thats the log from FSUIPC, and just shows that FSUIPC7 exited as MSFS was no longer available, presumably because it crashed. I need to see the WAPI log from your application. If you haven't set a name for the log file, then it should be called FSUIPC_WASMIF.log and be in the folder where you run the application, The FSUIPC_WASM_log file will be:

Quote

For Steam installs, in the following folder under your user account:
      AppData\Roaming\Microsoft Flight Simulator\Packages\fsuipc-lvar-module\work
For MS Store installs, in the following folder under your user account:
      AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\Packages\fsuipc-lvarmodule\work
The FSUIPC WASM log file (FSUIPC_WASM.log) can also be found in this location.

You should also set debug level logging in both the WAPI (i.e. in your application) and in the WASM - using the FSUIPC_WASM.ini file (see Advanced User guide for details).

John

Posted

Just checked the code and I have found a possible issue that could cause this - lvar and hvar CDAs are dropped when closing down, but I made change in the last beta to drop these once they have been processed, so the close function is trying to drop CDAs that have already been dropped.

I will correct this and provide an update build here for you to test.

John

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.