Jump to content
The simFlight Network Forums

Joerg Alvermann

Members
  • Posts

    11
  • Joined

  • Last visited

Posts posted by Joerg Alvermann

  1. 1 hour ago, Pete Dowson said:

    But Simconnect.cfg is only ever used or needed for a Networked connection to SimConnect on the P3D PC. The file used locally is Simconnect.xml, butt the default settings for that are fine and suite all local applications and only needs modifying for remote use.

    Everything else using SimConnect is running fine.

    Anyway, it is obvious to me now that this is NOT the place for reports about PMDG problems -- they need to be posted to PMDG's Support as only they can do anything with them.

    Pete

     

    Of course, you're right. I meant simconnect.xml when I wrote simconnect.cfg.
    In my case simconnect.xml was completely missing in C:\Users\...\AppData\Roaming\Lockheed Martin\Prepar3d V4 when PMDG 747 was not loading at all in V4

    Copying simconnect.xml from v3 solved it for me.

    Joerg

  2. 7 hours ago, Pete Dowson said:

    PMDG have sent me a v3 747 to test with, but when I load it, no matter whether FSUIPC is registered or not, or even installed, P3D4 hangs with a black screen, no menu, no progress bar, no nothing!

     

    Hi Pete,

    that's probably** due to simconnect not able to initialize properly. I had the same behaviour on my system.
    At my end it was only simconnect.cfg missing in ../AppData/Roaming/Lockheed Martin/Prepar3d v4 
    I copied the one from v3 to solve this.

    Joerg

    ** P.S.You should have a logfile in the PMDG/QOTS (don't have the exact name atm) subfolder within the P3Dv4 main folder  

  3. 11 hours ago, Pete Dowson said:

    Can those suffering from any of the problems detailed in this thread please now download FSUIPC 4.959m from the Download Links subforum above, and let me know if this fixes things.

    while I haven't experienced the 'crash on reload' since I reset my NVIDIA driver (see above), i had two smaller issues, both not impacting P3D restarts, remaining:

    1. P3D crashing in exit
    2. Three suspicious entries in the Windows Event Viewer log on every P3D closure

    I installed 4.959m and applied

    Debug=Please
    LogExtras=5
    TimeForLuaClosing=0

    Result: All good now. Both errors are gone now. No crash on exit, No entries in the Windows Event Viewer log on P3D closure

    FSUIPC4.log attached

    Joerg

    FSUIPC4.log

  4. 50 minutes ago, guenseli said:

    So, first startup with 

    UpdatedByVersion=4959

    FSVersionUsed="Lockheed Martin® Prepar3D® v3",3.4.18.19475
    SimConnectUsed=3.4.0.0

    is working

    Guenther, do you use by any chance multiple displays in an NVIDIA Surround config? 

    I was finally able to eliminate the P3D crash on startup with 4.959 and 4.959e by resetting my NVIDIA Surround configuration.
    A new system setup is basically nothing different. Would explain why it is now working for you.

    Pete, I just send you a mail with my findings.

    It looks like the installation of HF2 requires also some sort of 'reset' of the NVIDIA graphics driver.
    The following procudere is probably good for most users to solve the P3D crash on startup issue.  

    ALL, PLEASE Report back if it helps or  not!

    This is based on my system with Nvidia Driver 376.33 WHQL Win10 64 bit

    1. If you use NVidia Surround, disable Nvidia Surround

    2. If you use NVIDIA Profile Inspector, reset the Prepar3D profile to NVIDIA Defaults

    3. Locate your Prepar3d.cfg 

    4. Delete prepar3d.cfg and continue with 6.
       OR  
    5. modify prepar3d.cfg as follows

    5.a. in section [MAIN] delete the 2 lines 

         LocationFullScreen=0,0,5760,1200,\\.\DISPLAY1
         Location=87,0,5760,1200,\\.\DISPLAY1

    5.b  delete WHOLE sections (i.e. both lines) of ALL occurences (you'll find 1 entry for each active physical screen if not on NVIDIA Surround)

         [DISPLAY.Device.NVIDIA GeForce GTX 980 Ti.0.0]     <= Exact line differs based on your GPU
         Mode=5760x1200x32                        <= Exact line differs based on your Screen resolution 

         [DISPLAY.Device.NVIDIA GeForce GTX 980 Ti.0.1]
         Mode=1920x1200x32

         [DISPLAY.Device.NVIDIA GeForce GTX 980 Ti.0.2]
         Mode=1920x1200x32

    5.c  save & close prepar3d.cfg

    6. Reboot 

    7. It's a good idea to run FSUIPC4 Install.exe to clean remaining issues of earlier P3D crashes (those we want to fix)

    8. Run P3D, let the the default flight load, and wait for all addons to complete their startup / initialization

    9. close P3D and wait till the process prepar3d.exe has been terminated completely 
       use task manager or tool of your choice to check there is no running proess of prepar3d.exe remianing

    10. start P3D again and check whether it's still crashing (it shouldn't though there might be other reasons causing P3D to crash) 

    11. close P3D

    done

    12. now you can configure NVIDIA surround, NVIDIA Inspector, resolution etc. as you like

  5. 2 hours ago, Pete Dowson said:

    More to the point, was P3D alwats restartable without crash afterwards?

    affirmed

    2 hours ago, Pete Dowson said:

    Or can someone suggest a simple LINDA install without much configuring, or with a ready-made configuration, which will do the trick?

    Apart from my VRInsight MCP Combo II I have not much programmed/assigned/configured in LINDA, so a very simple LINDA install might be enough to force the error.
    Simple LINDA install from my perspective would mean:

    1. Unzip the LINDA Package in the respective folders
    2. Run LINDA.exe once to do and save the basic configuration
    3. Run P3D

    --

    While i'm a happy camper with the P3dhacks=x80 now, I've done some further testing

    P3dhacks=x80 disabled
    All LINDA lua scripts deactivated
    had ipcReady.lua run a simple lua script which basically only calls ipc.display() 

    This 'simple' ipc.display() call was not able to reproduce the error. Reactivating the LINDA lua package also reactivates the error.
    This seems to support the theory of timing / display facility issues.

    Joerg

  6. 1 hour ago, Pete Dowson said:

    Another test which you could do. If you set

    P3dhacks=x80

    Yes, this also does the trick, i.e. preventing P3D crash on exit (with the advantage over disabling pic.display() that LINDA messages are still displayed, in the P3D default text window this time)

    However, but this is probably expected, P3dhacks=x80 with 4.958 gives me P3D crash on exit

    And i can confirm that - even if P3D crashes on exit - P3D 3.4 HF2 starts again without problems when 4.958 is installed.

    Thinking about changes between 4.958 and 4.959, while there are not necessarily obvious changes, maybe some subtile ones, where WIn7 more tolerant than Win10?

    I don't have a clue about digital signatures and so forth, but could by any chance this 

    cause Win10 signature probing to fail and crash P3D? Maybe worth checking with this little nuance in the dll corrected? Just - and probably a very stupid - idea.

  7. 57 minutes ago, Pete Dowson said:

    You could try avoiding it again, as a test. Add this to the [General] section of FSUIPC4.INI (or change it if already there).

    CallSimconnectEnd=No

    Tested. With or without that entry, results are the same. P3D crash on exit under certain circumstances:

    My assumption is still: The P3D crash on exit is the root cause for the reported failures on subsequent P3D starts. And since I can reproduce the P3D crash on exit with LINDA in place I tried to eliminate that LINDA function which might cause P3D to crash on exit. 

    At the end I found 'ipc.display()' at least suspicious. If I eliminate (i.e. comment out)  all 'ipc.display()' function calls in the LUA scripts provided by LINDA, P3D closes normal, and i have no issues on following P3D starts.

    As soon as ipc.display() is called only one time,  and I close P3D afterwards, I get the "prepar3d.exe stopped working" message, i.e. P3D crash on exit.

    Joerg

  8. can confirm i'm on Windows 10

    19 hours ago, guenseli said:

    The issue begins when I send my computer to sleep or shut down for some time, hope you've taken this into account with your tests. (But I don't know if thats the case with others, too. But it is here a 100% reproduceable thing)

    i can't second that. I have no issues after sending my computer to sleep. P3D start is normal.

    ==

    Let me try to summarize my view:

    On my system,

    - the P3D crash on startup (i.e. the main issue reported with 4.959 & HF2, were discussing here) is ONLY happening, once i had an P3D "crash on exit" (i.e. the Windows Dialog stating that prepar3d.exe stopped working, when closing P3D).

    - It requires GSX (i.e. couatl.exe and bglman.exe, latest versions here) AND linda.lua to be active to reproduce this "crash on exit"

    - i don't recall when this 'crash on exit' has been introduced, but it's happening for quite some time (i.e. also monitored with previous versions of FSUIPC, LINDA, GSX. I also I think i monitored it on Win7 already, but am not sure on this) Difference to previous versions however: It's only now (i.e. with 4.959 & HF2) that this 'crash on exit' it's really affecting subsequent starts of P3D

    Would be interesting to hear from others affected by the Topic issue, whether they as well have P3D 'crash on exit' after a fresh FSUIPC install.

    Pete, you probably did test this when trying to reproduce, but out of curiosity: You mentioned GSX present on your system. Did you also have LINDA installed & active during your tests?

    Joerg

    P.S. Some spare time to help further analyzing. PM me if i can help

  9. 2 minutes ago, Pete Dowson said:

    You mean the "crash" which is actually a "minimise" action? Won't it restore if you click it?

    Those points need reporting to L-M please.

    I've not heard of any "minimise" problem before. The 100% core utilisation sounds very odd indeed, and the DXDiag does seem related to devices -- back to LINDA I suppose. Maybe a process of elimination on what LINDA is doing would be useful? I know L-M were making quite a lot of changes to the way they were handling devices, even with choices between DirectX use and the older style device driving.

    Pete

     

    There is no GUI element left to klick on after the 'crash' or 'minimise'. i.e. there is only the process, but no app listed in the task manager. Will report to LM after this weekend.

    On the GSX Topic:

    I just tested an can confirm:

    - LINDA only (i.e. no COUATL.exe, no AddOnManager): NO P3D crash on exit. NO subsequent failure on P3D start

    - LINDA and COUATL but No AddOnManager:     NO P3D crash on exit. NO subsequent failure on P3D start

    - LINDA and COUATL and AddOnManager:    P3D crash on exit. Subsequent failure on P3D start

    - NO LINDA, but COUATL and AddOnManager:  NO P3D crash on exit. NO subsequent failure on P3D start

    Reinstallation of the FSDreamTeam AddOnManager resolves the issue. Just like the installation Routine of FSUIPC.

    Could it be that the P3D crash on exit leaves one/some files in a unclean state which causes the subsequent failure (i.e. crash or minimize during start), and any installation routine touching this file / those files with a complete open, read/write, close brings them back in a normal state?

    Joerg

  10. 1 hour ago, Pete Dowson said:

    Ah, so could the apparently successful sessions actually be crashing on exit without you noticing? Can you check the Event Viewer logs in Windows to see? On a successful run, is the FSUIPC log file complete with the end summaries?

    The crash on exit is always noticed. On closure of P3D it takes a couple of seconds before a Windows dialog is popping up stating that prepar3d.exe stopped working. It's the closing issue you're discussing with the LINDA Dev in another thread which you already referenced above.

    FSUIPC log however is complete with end summaries.

    1 hour ago, Pete Dowson said:

    Try a re-boot instead of an FSUIPC reinstall.

    re-boot does not help in the case we discuss. FSUIPC reinstall seems so far to be the only thing to allow P3D to start again. As reported by other users as well. So it must change something to the good. Maybe a changed timestamp on a file or advanced file attributes?

    btw other things noticed related to this crash (not the crash on exit)

    - prepar3d.exe remains running (with 100% utilization of 1 core)

    - dxdiag seems to be called producing a dxdiag log file in AppData Roaming

    Joerg

    P.S: would like to help analyze further, but won't be available to do so before sunday.

     

  11. Well, for me it looks indeed like LINDA - specific linda.lua - is triggering the P3D crash. P3D stops crashing when I remove 'linda.lua' file from the Modules folder. Though I have to check whether removing 'linda.lua' from the Modules folder is sufficient IF the P3D crash already happened once, or a new run of FSUIPC Installation is required too.

    The odd thing however is that after running the FSUIPC installation routine, once i move linda.lua back into the Modules folder, it will run once without problems. Only from the 2nd P3D start onwards it triggers the crash.

    P.S: linda.lua is triggered by ipcReady.lua which - of course - needs to be present as well, and is NOT causing any issue if it remains present in the Modules folder

     

    LATER after further testing: 

    Fresh FSUIPC install, LINDA present: P3D start as normal, BUT P3D crashes when it's closed. This is a known (LINDA-) issue and had happened since P3D 3.4 without effecting subsequent starts of P3D. This seems to have changed with HF2 where LM also has changed some exception handling (according to Beau Hollis in the LM forum). The P3D crash on exit seems to leave the system in an unclean state which causes the crash on the next attempt to start P3D.  Removing linda.lua from the Modules folder does not help if P3D already crashed once on exit, but removing linda.lua before the first (after FSUIPC install) P3D run prevents P3D to crash on exit, i.e. the system remains in a 'clean' state when closing P3D.

    Obviously the Installation routine of FSUIPC however seems to 'resets' the system to a clean state, which - according to everything above - points to the DLL.XML (in AppData Roming) file again.

    Joerg

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