kingm56 Posted February 26, 2023 Report Posted February 26, 2023 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.
Paul Henty Posted February 26, 2023 Report Posted February 26, 2023 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
John Dowson Posted February 26, 2023 Report Posted February 26, 2023 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
kingm56 Posted February 26, 2023 Author Report Posted February 26, 2023 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
John Dowson Posted February 26, 2023 Report Posted February 26, 2023 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
kingm56 Posted February 26, 2023 Author Report Posted February 26, 2023 Thanks, John; I was actually thinking the same as I had a similar issue when SU10 was officially released.
Paul Henty Posted February 26, 2023 Report Posted February 26, 2023 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
kingm56 Posted February 26, 2023 Author Report Posted February 26, 2023 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.
John Dowson Posted February 27, 2023 Report Posted February 27, 2023 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
John Dowson Posted February 27, 2023 Report Posted February 27, 2023 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
John Dowson Posted February 28, 2023 Report Posted February 28, 2023 Could you please try the following build: FSUIPC WASM Module 1.0.0 + WAPI 1.0.1 John P.S. If you have problems downloading by clicking the link, try right-click and save as. There can be issues as the link is on http not https, so you may have to accept or disregard any browser warnings.
kingm56 Posted March 1, 2023 Author Report Posted March 1, 2023 Thanks John! I will test this evening and get back with you.
kingm56 Posted March 2, 2023 Author Report Posted March 2, 2023 Worked perfectly, John. Thank you for the quick fix! Matt
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now