John Dowson

MakeRunways is a separate download, and is compatible with all versions of P3D, FS2002, FS2004, FSX and MSFS (all on Windows 10). It is available from www.fsuipc.com or the download section in this forum. If you already have it installed, it should work with MSFS, but make sure you are using the latest version. John

Ok, thanks - and yes, please update if you manage to resolve. One thing though, on this: Has the com bit-speed been changed to use that required by the device? Maybe worth double-checking. Other than that, good luck and please report back if/when you manage to solve. John

Your FSUIPC7.log file shows that it was MSFS that crashed, and FSUIPC7 exited normally: FSUIPC7 will exit when MSFS CTDs. If you check your Event viewer logs, I'm sure you will see and MSFS crash report entry before that of FSUIPC7. As O said, when MSFS CTDs, this creates an exception in FSUIPC7 as the SimConnect handle is no longer valid. This will generate fault reports in FSUIPC, but they are handled gracefully. However, when FSUIPC7 is auto-started by MSFS, it must close when MSFS is no longer available, otherwise the MSFS process will not exit cleanly. So, your problem is with MSFS - you need to check the Asobo forums on CTD issues and raise a new report if necessary. If you want to verify this, start FSUIPC7 manually BEFORE you start MSFS, and uncheck the option Exit with FS. You will get an error when MSFS tries to start FSUIPC7, but this can be ignored. When you do this, you will see that if/when MSFS CTDs, FSUIPC7 keeps running. So the promlem is with MSFS/Asobo, not FSUIPC. John

Previous license only expired yesterday. I will generate a new one in a couple of days. John

FSUIPC7 doesn't do anything with devices unless you tell it to. In fact, I don't think it will even recognise the devices unless you have installed any specific drivers so that they are recognised as HID joystick type devices. Maybe you can show me your FSUIPC7.log and FSUIPC7.ini files. Do you have the FSIOPC7 WASM module installed? If so, maybe test with removing that temporarily from your MSFS Community folder, to see if there is an issue with overlapping events. You can also try activating logging for Events to see what, if any, events are being sent that could maybe explain the behaviur you are seeing. I believe so, although I haven't actually used SPAD.next with FSUIPC7, only with FSUIPC6/5 and P3D. It integrates well with FSUIPC on those platforms, but you may wish to confirm about MSFS on SPAD.next support.

I have just checked your details here and they validate fine - are you sure that you are entering them correctly? Did you try running FSUIPC7 - does it run ok? I will PM you a key file with your registration details and you can try that. John

First, please download and update to v7.2.8. Then replace the FSUIPC7.exe with the attached one and try again: FSUIPC7.exe If you still get a CTD, please show me your FSUIPC7.log and FSUIPC7.ini files, as well as the Event viewer info, thanks. The Event viewer info you posted shows that it was MSFS that actually crashed first, causing an issue in FSUIPC7 afterwards. If you check your FSUIPC7.log file, you will most probably find that it exited automatically due to MSFS crashing.

There was a dereferencing error on adding an lvar to an offset with the format UD which has now been corrected. Sorry about that. John

I thought you were using 7.2.0d? Please try the attached version. You will need to re-install 7.2.8 first (as the 0.5.4 WASM is needed): FSUIPC7.exe

I have just checked your details and they verify correctly here, in both the installer and in FSUIPC7. So, please follow the instructions on re-installing the VC++ redistributables from the provided README.txt,

That WASM log is from a different session to your FSUIPC7.log. I always need to see both files from the same session. Please remember always to attach both. And was Debug (or Trace) logging enabled in the WASM? Keep Debug logging on, as a minimum, for the time being. Other than that, your log files show that the WASM & FSUIPC7 are running normally, and you are sitting in the main menu having not loaded an a/c yet. That is a very old version, not the previous version. This version works for most people (i.e. everyone else!), I don't know what your issue is. Did you try disabling everything else (e.g. VRI device) for the time being, as advised?

Can you try downloading again and re-installing. This is very strange.....

Your logs show it crashing (or stopping) at different times. Very strange. Do you have anything else running? Maybe disable your VRI device (rename the driver) and stop anything else running for the time being.

I need to see your FSUIPC_WASM. log as well please...and also check for application events...

And can you activate Trace logging in the WASM please? Everything looks ok so far in the logs provided, Can you maybe also try setting the LvarScanDelay parameter in the FSUIPC7_WASM.ini to , say, 45 or so (min 30). This will delay the scanning of lvars until the A320 is fully loaded, which takes time.

Please NEVER post your key details in a public forum - this violates the license policy. I have removed them from your post, but If you post your key details again they will be banned from subsequent releases of FSUIPC7. You also posted in the wrong forum - please post in the FSUIPC7 / MSFS sub-forum for issues with FSUIPC7. Did you read the section 'Invalid Key Problems' in the Installation and Registration guide? If not, please do that first. Not sure what that means. Your question only just came through (for approval) for some reason.

So it is crashing? i.e. there is not process still running? Presume its also not in the system tray. no? Or is there a process still running/visible? I'm sorry but I am asking specific questions and you are continuing to be vague (continually just saying it has 'stopped'). I am trying to determine if the process is still running or not - it is either still running (but not working/doing anything) or has crashed - which is it? By 'stopped' do you mean has 'crashed'? Not sure what 'logbooks' is - did you check the application events? Of it has crashed (not just 'stopped'), then there should be an event logged. Try searching for it - or check the Advanced User Guide, P45: Your log files are showing different numbers of lvars found each time, and is stopping (or the log is ending) at different places each time. Very strange. Could you tell me how you installed the FBW A320, as previously asked - using the FBW installer or the MSFS Marketplace? And are you using the latest version? Maybe also test with anything else (e.g. MF WASM module) removed from your community folder - just leave the FBW A320 and the FSUIPC WASM modules for now.

So its not in the task bar or system tray, but the process is still running? And there is nothing in the Event viewer? How strange.... Have you restarted MSFS? If not, please do that - in fact, please reboot and try again. If the problem persists, enable Debug logging in the WASM, and show me the FSUIPC_WASM.log together with your FSUIPC7.log generated at the same time. Also, which FBW version of the A320 are you using (stable, dev or experimental), and is it installed via the Marketplace or the FBW installer?

Do you mean that its still running (visible?) but doesn't react to any user input (even alt + F hide/show)? Or do you mean that your controls/assignments are not working? Please explain what you mean.... Try setting the WAPI LogLevel to Trace on your FSUIPC7.ini and show me the log produced. The WAPI runs in a separate thread so I'm not sure how that can cause the other threads to stop responding. Did you have a aircraft loaded and ready-to-fly?

Did it crash? If so, can you please can you please see if there is anything in the Windows Event log, and if so please show it to me. Please try with no ini (i.e. rename your current FSUIPC7.ini temporarily) and another test with your current ini but the WAPI disabled (by changing your FSUIPC7.ini to disable it).

As your question is on MSFS / FSUIPC7, you should use the dedicated sub-forum for this - I have moved your post for you. First, can you check your MSFS assignments and make sure that you don't have any axes assigned there. Did you have an aircraft loaded and ready-to-fly before attempting to assign or calibrate your axis? Unfortunately I don't have any PFC devices and am not familiar with the PFC driver and assignments using that. Maybe @Pete Dowsonwill be able to help... John

Can you also use this version instead - it has extra logging enabled around running luas: FSUIPC6.dll

Could you expand on this please?

Yes, it looks like the Q400_GF_COM1.lua exited for some reason, but BEFORE you activated debug logging. Could you try and repeat this test but with lua debug logging activated from the start? If you can generate such a log file it should hopefully show what is happening in that module and why/when it is exiting. Also, it seems its only occurring with certain aircraft, when you have many modules/lua scripts running, no? Maybe its hitting some inbuilt/hard-coded limit somewhere. Does this issue always occur in the same module (Q400_GF_COM1.lua)? If so, maybe also try re-ordering the order that the lua scripts are started to see if the error occurs in the same or a different module.

It is better to stop everything else and try to reproduce the issue with the minimum number of luas running - hopefully just the one. Did you not try stopping most or all of your other luas and just leave the Q400_GF_COM1.lua running? If not, please try that first and let me know if you still get issues. If not, then try adding things back, one-by-one, until the issue occurs. Ah, so the issue occurs with only one module running? So the event.timer function that runs every second shouldn't have been running, no? But even if it was and the log was huge, please zip it up and attach. I really do need to see the whole log, not just extracts. And no need to add such logging statements - you should just enable lua debug logging, as this will log each line executed. Yes, but I cannot tell if the button was triggered or not when you post selected extracts, which is one reason why I need to see the full log. From that extract, I do not know what logging was activated, for example. I would like to see a full log file of your issue with the simplest possible set-up, hopefully with just one lua running. And then reproduce here so I can investigate. John