FSDreamTeam forum
Products Support => GSX Support FSX/P3D => Topic started by: p3dx3 on May 20, 2018, 04:56:36 pm
-
For a week I have tried to find the solution to a crash on exit, prepar3d.cfg.txt is created and Windows Event Viewer says api.dll crash after I fly then exit
I removed the folder from the prepar3d addons in my docs "fsdreamteam addon manager"
p3d quits without crashing.
Updated using Live Update
putting the addon manager back in the addon folder, p3d says to activate, start a flight, quit, the api.dll crash is back
Windows 10 Professional and the latest big update installed. Current drivers for Nvidia video card.
Faulting application name: Prepar3D.exe, version: 4.2.21.24048, time stamp: 0x5a7c832c
Faulting module name: api.dll, version: 4.2.21.24048, time stamp: 0x5a7c83e1
Exception code: 0xc0000005
Fault offset: 0x0000000000015611
Faulting process id: 0x538
Faulting application start time: 0x01d3eafa98c82a0f
Faulting application path: C:\Lockheed Martin\Prepar3D v4\Prepar3D.exe
Faulting module path: C:\Lockheed Martin\Prepar3D v4\api.dll
Report Id: c096d707-1fff-4b68-9905-6a464aab563f
Faulting package full name:
Faulting package-relative application ID:
-
We are aware of this, and are investigating it.
-
Hi,
Just to confirm that I too am experiencing the crash on exit from Prepar3D v4.2.21.24048 under Windows 7 Pro 64bit SP1.
This only happens while exiting from the fully loaded sim and not from the Prepar3D Scenario screen. Disabling the FSDreamTeam Addon Manager appears to 'resolve' the issue and P3D exits gracefully. I have only tested in the fully loaded default scenario situation.
Prior to the recent Couatl update this was never an issue and I've been using GSX Ground Services since 12/2017.
Event Viewer reports:
Problem signature:
Problem Event Name: APPCRASH
Application Name: Prepar3D.exe
Application Version: 4.2.21.24048
Application Timestamp: 5a7c832c
Fault Module Name: api.dll
Fault Module Version: 4.2.21.24048
Fault Module Timestamp: 5a7c83e1
Exception Code: c0000005
Exception Offset: 0000000000015611
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 2057
Additional Information 1: 4df1
Additional Information 2: 4df16727dc39edd0dd79a54706d266f6
Additional Information 3: e7c7
Additional Information 4: e7c773fff755952d612832c9c2577e0b
Regards,
Mike
-
The problem is now fixed in the latest Live Update we released today.
-
The problem is not fixed in the latest Live Update we released today.
Hi Umberto,
This topic has been marked as **SOLVED** and yet you appear to be stating that the problem is not fixed? Please forgive me for feeling a little confused. Perhaps best if I simply go ahead and apply the latest update and find out for myself.
Thanks.
Regards,
Mike
-
The problem is not fixed in the latest Live Update we released today.
Hi Umberto,
This topic has been marked as **SOLVED** and yet you appear to be stating that the problem is not fixed? Please forgive me for feeling a little confused. Perhaps best if I simply go ahead and apply the latest update and find out for myself.
Thanks.
Regards,
Mike
he could mean it is fixed, and run the live update as administrator to update
-
Just checked and, sadly, the problem persists: Exit the sim via End Scenario and....
Log Name: Application
Source: Application Error
Date: 22/05/2018 15:47:31
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Prometheus
Description:
Faulting application name: Prepar3D.exe, version: 4.2.21.24048, time stamp: 0x5a7c832c
Faulting module name: api.dll, version: 4.2.21.24048, time stamp: 0x5a7c83e1
Exception code: 0xc0000005
Fault offset: 0x0000000000015614
Faulting process id: 0x276c
Faulting application start time: 0x01d3f1db4e07472c
Faulting application path: D:\Lockheed Martin\Prepar3D v4\Prepar3D.exe
Faulting module path: D:\Lockheed Martin\Prepar3D v4\api.dll
Report Id: 0dc49dd0-5dcf-11e8-90ed-40e230989421
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-05-22T14:47:31.000000000Z" />
<EventRecordID>234398</EventRecordID>
<Channel>Application</Channel>
<Computer>Prometheus</Computer>
<Security />
</System>
<EventData>
<Data>Prepar3D.exe</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c832c</Data>
<Data>api.dll</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c83e1</Data>
<Data>c0000005</Data>
<Data>0000000000015614</Data>
<Data>276c</Data>
<Data>01d3f1db4e07472c</Data>
<Data>D:\Lockheed Martin\Prepar3D v4\Prepar3D.exe</Data>
<Data>D:\Lockheed Martin\Prepar3D v4\api.dll</Data>
<Data>0dc49dd0-5dcf-11e8-90ed-40e230989421</Data>
</EventData>
</Event>
I'll try running the Live Update again as Administrator although, strictly speaking, that should not be necessary.
Mike
-
Ran the FSDT Live Update as Administrator:
Hmm, that worked....once!
The sim crashed on exit with the next 2 attempts. Each time after about 30secs which seems to be the 'normal' behaviour. Same error reported in the Event Viewer.
I performed a System Restart and tried again (Default Flight and via End Scenario) - First time successful, second crashed, third successful, fourth crashed.
The next 3 exit attempts were straightforward Exits (not involving the End Scenario option) and 2 were successful with no reported errors and the 3rd crashed:
Log Name: Application
Source: Application Error
Date: 22/05/2018 16:42:36
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Prometheus
Description:
Faulting application name: Prepar3D.exe, version: 4.2.21.24048, time stamp: 0x5a7c832c
Faulting module name: api.dll, version: 4.2.21.24048, time stamp: 0x5a7c83e1
Exception code: 0xc0000005
Fault offset: 0x0000000000015611
Faulting process id: 0x19f0
Faulting application start time: 0x01d3f1e2eca6a631
Faulting application path: D:\Lockheed Martin\Prepar3D v4\Prepar3D.exe
Faulting module path: D:\Lockheed Martin\Prepar3D v4\api.dll
Report Id: bfcc1364-5dd6-11e8-8450-40e230989421
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-05-22T15:42:36.000000000Z" />
<EventRecordID>234471</EventRecordID>
<Channel>Application</Channel>
<Computer>Prometheus</Computer>
<Security />
</System>
<EventData>
<Data>Prepar3D.exe</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c832c</Data>
<Data>api.dll</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c83e1</Data>
<Data>c0000005</Data>
<Data>0000000000015611</Data>
<Data>19f0</Data>
<Data>01d3f1e2eca6a631</Data>
<Data>D:\Lockheed Martin\Prepar3D v4\Prepar3D.exe</Data>
<Data>D:\Lockheed Martin\Prepar3D v4\api.dll</Data>
<Data>bfcc1364-5dd6-11e8-8450-40e230989421</Data>
</EventData>
</Event>
So, sorry to say that with the FSDT Addon Manager/GSX enabled sim exit behaviour still remains flaky.
Hope this has been of some help, Umberto.
Regards,
Mike
-
I'm sorry, but I cannot reproduce this.
- I could see the API.DLL crash on exit 100% of the times with the old version
- I have 0% crashes with the current one so, it's 100% clearly reproducible.
The only file that affects this is bglmanx.dll, under the Addon Manager folder. To be sure you have the fixed version, check it's version 4.5.0.2 and its digital signature has a timestamp of May 22th 2018.
-
This topic has been marked as **SOLVED** and yet you appear to be stating that the problem is not fixed?
The browser auto-correct changed my original sentence "it's now fixed", into "it's not fixed". Now, even the sentence is fixed...
-
I'm sorry, but I cannot reproduce this.
The only file that affects this is bglmanx.dll, under the Addon Manager folder. To be sure you have the fixed version, check it's version 4.5.0.2 and its digital signature has a timestamp of May 22th 2018.
Hi Umberto,
Looks like I do have the latest 'fixed' file:
(https://i.imgur.com/YDmTxhe.jpg)
Regards,
Mike
-
Looks like I do have the latest 'fixed' file:
Then I'm sorry, but I can only repeat and confirm the crash cannot happen with that version. Are you SURE you are looking at an event which was generated after installing the latest version ?
-
Looks like I do have the latest 'fixed' file:
Then I'm sorry, but I can only repeat and confirm the crash cannot happen with that version. Are you SURE you are looking at an event which was generated after installing the latest version ?
Hi Umberto,
I do admire your confidence. However, there has to be a reason why my experience remains at variance with your conviction. Normally having such responses I would be suspecting something else was at play here. Unfortunately this would not explain why the FSDT Addon Manager/ Couatl / GSX was not hindering Prepar3D v4.2 from exiting gracefully prior to that update. I think at least we can agree that something changed with that update. You believe that it has been fixed and this is supported by your testing procedures. I acknowledge and, indeed, accept that to be the case.
Has the original main installer been updated? If so, then perhaps the logical next step would be for me to start again by obtaining a fresh download of the product from my account and then perform a clean reinstall.
I’ll report back later.
Thanks for your input.
Regards,
Mike
-
I do admire your confidence. However, there has to be a reason why my experience remains at variance with your conviction. Normally having such responses I would be suspecting something else was at play here.
That's likely.
API.DLL is related to Simconnect but, interestingly enough, the bug we FIXED in our program didn't had anything to do with Simconnect. It was purely something of an internal communication between the Addon Manager and Couatl, which use their own communication channel. It's also possibly related to the new PDK.
So, it's possible the issue happens also in combination with other addons, which also use the either Simconnect or the PDK.
Unfortunately this would not explain why the FSDT Addon Manager/ Couatl / GSX was not hindering Prepar3D v4.2 from exiting gracefully prior to that update. I think at least we can agree that something changed with that update.
In order to know what changed, we should know which exact release you had before the update.
You believe that it has been fixed and this is supported by your testing procedures. I acknowledge and, indeed, accept that to be the case.
As I've said in another post:
- When this issue has been reported, I checked it, and verified I had a crash on API.DLL on exit 100% of the times.
- After the update I don't crashes anymore.
Has the original main installer been updated? If so, then perhaps the logical next step would be for me to start again by obtaining a fresh download of the product from my account and then perform a clean reinstall.
I doubt it will make any difference, because the installer would download the same file as the updater. In fact, the installer *starts* the Live Updater, same as if you launched it manually.
A more meaningful test would be disabling all the other 3rd party modules, EXCEPT the Addon Manager, and see if there's still a crash.
-
Mabye I found something:
Are you running P3D4 As Administrator, which is NOT how it's installed by default ? I tried it and yes, I DO have the API.DLL crash, but only by changing the Compatibility settings to run As Admin.
That explains why I couldn't replicate it before: I was running the sim as installed by default by LM. Now that I can sill replicate it, there might be a chance of really fixing it.
-
API.DLL is related to Simconnect but, interestingly enough, the bug we FIXED in our program didn't had anything to do with Simconnect. It was purely something of an internal communication between the Addon Manager and Couatl, which use their own communication channel. It's also possibly related to the new PDK.
So, it's possible the issue happens also in combination with other addons, which also use the either Simconnect or the PDK.
If this is the case then the most likely candidate would be the recently released FSPS FFTF Dynamic utility App** which is configured to load/unload automatically with the sim.
In order to know what changed, we should know which exact release you had before the update.
I returned recently after a short holiday and ran the FSDT Live Updater as part of the sim loading process to the default Flight Situation. All was well until I updated again the following day and that's when the exit issue surfaced. So the version must have been the one immediately preceding the 'bugged' version.
Are you running P3D4 As Administrator, which is NOT how it's installed by default ? I tried it and yes, I DO have the API.DLL crash, but only by changing the Compatibility settings to run As Admin.
Now this struck a chord. I installed GSX Ground Services on 03/12/2017 and up until then it was my habit to install everything as Administrator. **Since then, in connection with FFTF Dynamic, I have had very interesting discussions with Steve Waite who has pointed out the error of my ways. Installers usually create their own permissions for access when it is necessary to do so. Imposing your own permissions can lead to problems and so it's best not to follow this route. Just double-click an installer and let it do what is necessary.
So, I tried modifying the Users permissions to the Addon Manager folder by allowing Modify and Write (the latter is checked automatically once Modify is checked. I've been through all my relevant P3D-related installations and treated them in the same way. This appears to have had no negative effects over the past couple of months so must be doing something right ;D Unfortunately this didn't resolve the exit issue so perhaps the 'damage' was not reversible in this instance. At this point I decided to carry out a clean reinstall of GSX.
"Has the original main installer been updated? If so, then perhaps the logical next step would be for me to start again by obtaining a fresh download of the product from my account and then perform a clean reinstall."
I doubt it will make any difference, because the installer would download the same file as the updater. In fact, the installer *starts* the Live Updater, same as if you launched it manually.
I'm sure you're right. However, too late..lol! GSX has been uninstalled earlier this afternoon (Scotland) and I'm about to carry out a fresh install using the latest downloaded installer.
Fingers crossed! I'll be sure to let you know the outcome.
Regards,
Mike
-
Hi Umberto,
Okay, here are my findings.
Prepar3D v4.2 EXIT RESULTS
Each occasion sim crashes on exit:
(https://i.imgur.com/FAmRkff.jpg)
(1) CLEAN reinstall of GSX Ground Services [E:\Program Files (x86)\Addon Manager]
(Run as administrator NOT selected):
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from Prepar3D Scenario screen) -> NO Crash
(2) FFTF Dynamic disabled:
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from Prepar3D Scenario screen) -> NO Crash
(3) Add-ons... DISABLED:
(https://i.imgur.com/KpvvfMV.jpg)
(https://i.imgur.com/kXnIKmT.jpg)
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> NO Crash
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from Prepar3D Scenario screen) -> NO Crash
(4) AppData
DLL.XML (Disabled = True):
(https://i.imgur.com/dRpmfl2.jpg)
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from Prepar3D Scenario screen) -> NO Crash
EXE.XML (Disabled = True)
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from Prepar3D Scenario screen) -> NO Crash
(5) ProgramData (dll.xml)
XMLTools64 (Disabled = True)
PMDG_HUD_interface (Disabled = True)
RAASPRO (Disabled = True)
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from Prepar3D Scenario screen) -> NO Crash
(6) ProgramData (exe.xml)
FFTF Dynamic P3Dv4 (Disabled = True)
See item (2)
-------------------------------------------------------------------------
(7) RE-ENABLED (4, 5 and 6)
Prepar3D CRASHED within a few seconds of appearance of splash screen
during initial load!
Log Name: Application
Source: Application Error
Date: 23/05/2018 22:55:10
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Prometheus
Description:
Faulting application name: Prepar3D.exe, version: 4.2.21.24048, time
stamp: 0x5a7c832c
Faulting module name: api.dll, version: 4.2.21.24048, time stamp:
0x5a7c83e1
Exception code: 0xc0000005
Fault offset: 0x0000000000015611
Faulting process id: 0x2154
Faulting application start time: 0x01d3f2e048737023
Faulting application path: D:\Lockheed Martin\Prepar3D v4\Prepar3D.exe
Faulting module path: D:\Lockheed Martin\Prepar3D v4\api.dll
Report Id: f60330a3-5ed3-11e8-9f06-40e230989421
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-05-23T21:55:10.000000000Z" />
<EventRecordID>234800</EventRecordID>
<Channel>Application</Channel>
<Computer>Prometheus</Computer>
<Security />
</System>
<EventData>
<Data>Prepar3D.exe</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c832c</Data>
<Data>api.dll</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c83e1</Data>
<Data>c0000005</Data>
<Data>0000000000015611</Data>
<Data>2154</Data>
<Data>01d3f2e048737023</Data>
<Data>D:\Lockheed Martin\Prepar3D v4\Prepar3D.exe</Data>
<Data>D:\Lockheed Martin\Prepar3D v4\api.dll</Data>
<Data>f60330a3-5ed3-11e8-9f06-40e230989421</Data>
</EventData>
</Event>
------------------------------------------------------------------------
[8] SYSTEM RESTART:
Prepar3D Loaded successfully.
RE-ENABLED (3)
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
[9] Prepar3D Loaded successfully.
DISABLED FsDreamTeam Addon Manager and RESTART SIM
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> NO Crash
----------------------------------------------------------------------
So, the conclusion appears to be that no other Add-on is implicated in causing this behaviour.
Kind regards,
Mike
-
As I've said in my previous post, are you running P3D4 As Administrator, which is NOT how it's installed by default ? I tried it and yes, I DO have the API.DLL crash, but only by changing the Compatibility settings to run As Admin.
That explains why I couldn't replicate it before: I was running the sim as installed by default by LM. Now that I can sill replicate it, there might be a chance of really fixing it.
Could you please check if resetting P3D to default (NO Admin mode), fixes the crash ? We would like to know, which doesn't mean we'll not try to find the cause but, at least, it would be best being sure the issue is only caused by a configuration of the sim altered from the default installation.
-
As I've said in my previous post, are you running P3D4 As Administrator, which is NOT how it's installed by default ? I tried it and yes, I DO have the API.DLL crash, but only by changing the Compatibility settings to run As Admin.
That explains why I couldn't replicate it before: I was running the sim as installed by default by LM. Now that I can sill replicate it, there might be a chance of really fixing it.
Could you please check if resetting P3D to default (NO Admin mode), fixes the crash ? We would like to know, which doesn't mean we'll not try to find the cause but, at least, it would be best being sure the issue is only caused by a configuration of the sim altered from the default installation.
Hi Umberto,
I do apologise, I’m afraid I overlooked that for some reason. I became too focussed on the possibility that an Addon might be involved. At least we know now that is not the case. I’ll check ASAP. However, as part of my aforementioned discussions with Steve Waite I think that would have been checked and, if necessary, changed. I do recall changing Users permissions on the Lockheed Martin folder to allow Modify and Write.
Regards,
Mike
-
maybe I found something, could you please try this version, to overwrite the one in \Addon Manager ?
http://update.fsdreamteam.com/LOG/bglmanx.dll
-
maybe I found something, could you please try this version, to overwrite the one in \Addon Manager ?
http://update.fsdreamteam.com/LOG/bglmanx.dll
Hi Umberto,
Like you, I too thought I had stumbled on something but, sadly, it was not to be.
I checked the Priviledge Level of Prepar3D.exe and was somewhat surprised to find:
(https://i.imgur.com/7Oo6rSQ.jpg)
So, the box was unchecked and I ran P3D only to have this popup appear during initial loading:
(https://i.imgur.com/3twcjWT.jpg)
The Sim crashed on EXIT as on previous occasions. I rechecked the Priviledge Level of Prepar3D.exe:
(https://i.imgur.com/kjXIqaM.jpg)
So, at this point, it was reasonable to assume that FSLabs might be the culprit as it was resetting the Privilege Level!
I ran the Sim again and disabled Flight Sim Labs Products, but not Flight Sim Labs Spotlights, and tried again.
This time the Priviedge Level of Prepar3D.exe remained unchanged (box unchecked).
The Sim was restarted and crashed on EXIT as before. Same error, etc.
I tried the substitution of bglmanx.dll with the new one you provided but, again, with the same result: Sim crashed on EXIT.
Frustrating!
Regards,
Mike
-
I tried the substitution of bglmanx.dll with the new one you provided but, again, with the same result: Sim crashed on EXIT.
Please be sure of this:
- Is P3D now running as default, with No Admin rights ?
- Are you sure you temporarily disabled ALL addons, except the Addon Manager. To do this, you must be sure you disabled each and every addon in the Options->Add-ons menu AND each and every addon in all 4 XML files:
%APPDATA%\Lockheed Martin\Prepar3d v4\DLL.XML
%APPDATA%\Lockheed Martin\Prepar3d v4\EXE.XML
%PROGRAMDATA%\Lockheed Martin\Prepar3d v4\DLL.XML
%PROGRAMDATA%\Lockheed Martin\Prepar3d v4\EXE.XML
- Are you using the bglmanx.dll I just posted ?
I'm trying to let you ending in the same situation as I'm now: no crashes on exit with the Addon Manager enabled, and nothing else.
-
Hi Umberto,
I didn’t test your posted bglmanx.dll with that configuration as everything had been re-enabled after testing (see 6 posts above) with the exception of the FSLabs Flight Sim Products Add-on entry.
I will do so now.
Regards,
Mike
-
Okay Umberto, first to confirm we are now both on the same page:
(https://i.imgur.com/EGCTezp.jpg)
(https://i.imgur.com/5SHscps.jpg)
(https://i.imgur.com/1iOynNo.jpg)
(https://i.imgur.com/gz86sul.jpg)
(https://i.imgur.com/nOPIlFB.jpg)
(https://i.imgur.com/2bK6UwP.jpg)
Note: No Add-ons item on the Menu bar
(https://i.imgur.com/a6EebDy.jpg)
EXIT RESULTS:
(1a) Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> NO Crash
(1b) Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> "Couatl Scripting Engine for FSX/ESP has stopped working"
Log Name: Application
Source: Application Error
Date: 24/05/2018 16:01:37
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Prometheus
Description:
Faulting application name: Couatl.exe, version: 3.2.0.3995, time stamp: 0x5b03513f
Faulting module name: Couatl.exe, version: 3.2.0.3995, time stamp: 0x5b03513f
Exception code: 0xc0000005
Fault offset: 0x00056fa4
Faulting process id: 0x28b4
Faulting application start time: 0x01d3f36fdbcf4d33
Faulting application path: E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe
Faulting module path: E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe
Report Id: 5b0a2d18-5f63-11e8-816d-40e230989421
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-05-24T15:01:37.000000000Z" />
<EventRecordID>235000</EventRecordID>
<Channel>Application</Channel>
<Computer>Prometheus</Computer>
<Security />
</System>
<EventData>
<Data>Couatl.exe</Data>
<Data>3.2.0.3995</Data>
<Data>5b03513f</Data>
<Data>Couatl.exe</Data>
<Data>3.2.0.3995</Data>
<Data>5b03513f</Data>
<Data>c0000005</Data>
<Data>00056fa4</Data>
<Data>28b4</Data>
<Data>01d3f36fdbcf4d33</Data>
<Data>E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe</Data>
<Data>E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe</Data>
<Data>5b0a2d18-5f63-11e8-816d-40e230989421</Data>
</EventData>
</Event>
(2) End Scenario -> Exit Prepar3D -> Yes -> "Couatl Scripting Engine for FSX/ESP has stopped working"
(https://i.imgur.com/psbZ0AZ.jpg)
Log Name: Application
Source: Application Error
Date: 24/05/2018 15:48:47
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Prometheus
Description:
Faulting application name: Couatl.exe, version: 3.2.0.3995, time stamp: 0x5b03513f
Faulting module name: Couatl.exe, version: 3.2.0.3995, time stamp: 0x5b03513f
Exception code: 0xc0000005
Fault offset: 0x00056fa4
Faulting process id: 0x33e0
Faulting application start time: 0x01d3f36e1472edfe
Faulting application path: E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe
Faulting module path: E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe
Report Id: 90074d73-5f61-11e8-816d-40e230989421
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-05-24T14:48:47.000000000Z" />
<EventRecordID>234996</EventRecordID>
<Channel>Application</Channel>
<Computer>Prometheus</Computer>
<Security />
</System>
<EventData>
<Data>Couatl.exe</Data>
<Data>3.2.0.3995</Data>
<Data>5b03513f</Data>
<Data>Couatl.exe</Data>
<Data>3.2.0.3995</Data>
<Data>5b03513f</Data>
<Data>c0000005</Data>
<Data>00056fa4</Data>
<Data>33e0</Data>
<Data>01d3f36e1472edfe</Data>
<Data>E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe</Data>
<Data>E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe</Data>
<Data>90074d73-5f61-11e8-816d-40e230989421</Data>
</EventData>
</Event>
(3) Exit (from Prepar3D Scenario screen) -> "Couatl Scripting Engine for FSX/ESP has stopped working"
Log Name: Application
Source: Application Error
Date: 24/05/2018 15:54:26
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Prometheus
Description:
Faulting application name: Couatl.exe, version: 3.2.0.3995, time stamp: 0x5b03513f
Faulting module name: Couatl.exe, version: 3.2.0.3995, time stamp: 0x5b03513f
Exception code: 0xc0000005
Fault offset: 0x00056fa4
Faulting process id: 0x30e4
Faulting application start time: 0x01d3f36efde9610d
Faulting application path: E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe
Faulting module path: E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe
Report Id: 59d00134-5f62-11e8-816d-40e230989421
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-05-24T14:54:26.000000000Z" />
<EventRecordID>234998</EventRecordID>
<Channel>Application</Channel>
<Computer>Prometheus</Computer>
<Security />
</System>
<EventData>
<Data>Couatl.exe</Data>
<Data>3.2.0.3995</Data>
<Data>5b03513f</Data>
<Data>Couatl.exe</Data>
<Data>3.2.0.3995</Data>
<Data>5b03513f</Data>
<Data>c0000005</Data>
<Data>00056fa4</Data>
<Data>30e4</Data>
<Data>01d3f36efde9610d</Data>
<Data>E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe</Data>
<Data>E:\Program Files (x86)\Addon Manager\Couatl\Couatl.exe</Data>
<Data>59d00134-5f62-11e8-816d-40e230989421</Data>
</EventData>
</Event>
Regards,
Mike
-
If you change each dll and exe xml to utf-8 encoding instead of windows-1252? I am not at home to test yet
-
My compatibility check box for run as admin is not checked, but I right click the P3D shortcut and select run as administrator, every time I start. I do this to Activesky also
-
If you change each dll and exe xml to utf-8 encoding instead of windows-1252? I am not at home to test yet
That’s odd. I’m quite certain all these files were encoded UCS-2 LE BOM as I have been using Notepad++ to preserve the encoding and perform any editing. Yet now I see they have all been changed to Windows-1252 encoding.
I checked Prepar3D.cfg, Scenery.cfg and LWcfg.cfg.xml (just selected at random) and their encoded format remains as UCS-2 LE BOM.
Not sure whether this could be significant as the sim seems to be reading all these Windows-1252 encoded files without apparent problems as all my Add-ons are working.
I would be interested to read Umberto’s take on this and whether I should change the encoding. Why would it have an influence on the ‘Crash on EXIT’ issue with the FSDT Addon Manager in play?
Mike
-
If you change each dll and exe xml to utf-8 encoding instead of windows-1252? I am not at home to test yet
That’s odd. I’m quite certain all these files were encoded UCS-2 LE BOM as I have been using Notepad++ to preserve the encoding and perform any editing. Yet now I see they have all been changed to Windows-1252 encoding.
I checked Prepar3D.cfg, Scenery.cfg and LWcfg.cfg.xml (just selected at random) and their encoded format remains as UCS-2 LE BOM.
Not sure whether this could be significant as the sim seems to be reading all these Windows-1252 encoded files without apparent problems as all my Add-ons are working.
I would be interested to read Umberto’s take on this and whether I should change the encoding. Why would it have an influence on the ‘Crash on EXIT’ issue with the FSDT Addon Manager in play?
Mike
my reading of lockheed martin trying to set the standards, xml files are utf-8 and cfg files should be usc-2
-
Converted those 4 files to UTF-8 encoding. To make this stick I discovered I had to change the encoding first line entry in each file before running the conversion in Notepad++ (<?xml version="1.0" encoding="UTF-8"?>)
Carried out a System Reset - first of the day - and then reloaded the sim:
(https://i.imgur.com/Njsx23F.jpg)
Spot the difference? The Add-ons menu bar item has reappeared!
EXIT RESULTS:
Sim still crashing on exit with the original reported error implicating the api.dll as the faulting module. Had to test numerous times as the crash seemed more intermittent this time but overall was happening more often than not via all 3 aforementioned EXIT paths from the sim.
NO reappearance of the "Couatl Scripting Engine for FSX/ESP has stopped working" message.
Mike
-
I would be interested to read Umberto’s take on this and whether I should change the encoding. Why would it have an influence on the ‘Crash on EXIT’ issue with the FSDT Addon Manager in play?
There was (we thought it was fixed) a bug in P3D 4.0 that, if one DLL/EXE.XML was corrupted/illegal, it would prevent the sim from loading all addons, including the proper one (like our own), which DO NOT use the DLL/EXE.XML anymore, but use the add-on.xml method. Apparently, the bug is still there somehow.
As discussed in other threads, .CFG files are supposed to be UTF16-LE and they *must* be like that, because a .CFG file doesn't have any means to specify its encoding so, applications must agree on some standard.
XML files, instead, CAN specify their encoding so, the only requirement for them to be considered legal, is that the actual encoding of the file must be COHERENT with the encoding specified in their header. If there's NO header, the encoding is assumed to be UTF-8 with NO BOM. So, it's perfectly fine to have an XML encoded in ANSI or Latin-1 (windows 1252), as long the XML header says so. It's only when there's no header, that the file *must* be UTF-8 with no BOM.
But this doesn't have any relationship with the crash on Exit. A module is either loaded or not, it won't work any differently, just because it's XML was more or less correct.
There's not need to report back: we asked help to the "mothership" (Lockheed Martin), and they are helping us finding the cause.
-
We asked help to the "mothership" (Lockheed Martin), and they are helping us finding the cause.
"Mothership" replied and, it allowed us to find the cause. Try the FSDT Live Update again, to get the updated bglmanx64.dll (4.5.0.3), which should fix the problem.
Let me know if it works for you.
-
Thanks Umberto, also thanks to Lockheed Martin (assuming they are following this) for agreeing to become involved.
Ran FSDT Live Update (bglmanx64.dll updated to v4.5.0.3))
(https://i.imgur.com/SSQHHHZ.jpg)
Same Prepar3D v4.2 Add-on configuration as before (ALL DISABLED with exception of FSDT Addon Manager).
(1) EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> NO Crash
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
Log Name: Application
Source: Application Error
Date: 25/05/2018 13:48:36
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Prometheus
Description:
Faulting application name: Prepar3D.exe, version: 4.2.21.24048, time
stamp: 0x5a7c832c
Faulting module name: api.dll, version: 4.2.21.24048, time stamp:
0x5a7c83e1
Exception code: 0xc0000005
Fault offset: 0x0000000000015611
Faulting process id: 0x11a0
Faulting application start time: 0x01d3f4263b2b5846
Faulting application path: D:\Lockheed Martin\Prepar3D v4\Prepar3D.exe
Faulting module path: D:\Lockheed Martin\Prepar3D v4\api.dll
Report Id: f0699c02-6019-11e8-a0a9-40e230989421
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-05-25T12:48:36.000000000Z" />
<EventRecordID>235144</EventRecordID>
<Channel>Application</Channel>
<Computer>Prometheus</Computer>
<Security />
</System>
<EventData>
<Data>Prepar3D.exe</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c832c</Data>
<Data>api.dll</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c83e1</Data>
<Data>c0000005</Data>
<Data>0000000000015611</Data>
<Data>11a0</Data>
<Data>01d3f4263b2b5846</Data>
<Data>D:\Lockheed Martin\Prepar3D v4\Prepar3D.exe</Data>
<Data>D:\Lockheed Martin\Prepar3D v4\api.dll</Data>
<Data>f0699c02-6019-11e8-a0a9-40e230989421</Data>
</EventData>
</Event>
------------------------------------------------------------------------
Log Name: Application
Source: Windows Error Reporting
Date: 25/05/2018 13:49:45
Event ID: 1001
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: Prometheus
Description:
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: Prepar3D.exe
P2: 4.2.21.24048
P3: 5a7c832c
P4: api.dll
P5: 4.2.21.24048
P6: 5a7c83e1
P7: c0000005
P8: 0000000000015611
P9:
P10:
Attached files: (Also see foot of this post)
These files may be available here:
C:\Users\Cruachan\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Prepar3D.exe_3eda97622fa776e55c7d333f385aa57d58aa1ec_0afb5bf4
Analysis symbol:
Rechecking for solution: 0
Report Id: f0699c02-6019-11e8-a0a9-40e230989421
Report Status: 0
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Windows Error Reporting" />
<EventID Qualifiers="0">1001</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-05-25T12:49:45.000000000Z" />
<EventRecordID>235146</EventRecordID>
<Channel>Application</Channel>
<Computer>Prometheus</Computer>
<Security />
</System>
<EventData>
<Data>
</Data>
<Data>0</Data>
<Data>APPCRASH</Data>
<Data>Not available</Data>
<Data>0</Data>
<Data>Prepar3D.exe</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c832c</Data>
<Data>api.dll</Data>
<Data>4.2.21.24048</Data>
<Data>5a7c83e1</Data>
<Data>c0000005</Data>
<Data>0000000000015611</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>C:\Users\Cruachan\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Prepar3D.exe_3eda97622fa776e55c7d333f385aa57d58aa1ec_0afb5bf4</Data>
<Data>
</Data>
<Data>0</Data>
<Data>f0699c02-6019-11e8-a0a9-40e230989421</Data>
<Data>0</Data>
</EventData>
</Event>
SYSTEM RESTART
(2) EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> NO Crash
(3) EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
(4) EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> NO Crash
(5) EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
RESTORED previous bglmanx.dll (v4.5.0.2 (23/05/2018 20:27))
SYSTEM RESTART
(6) EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> NO Crash
(7) EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> CRASH
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
[8] EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> NO Crash
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
-----------------------------------------------------------------------
(9) EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> NO Crash
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> NO Crash
-----------------------------------------------------------------------
(10) EXIT RESULTS:
Exit (from Prepar3D Scenario screen) -> NO Crash
End Scenario -> Exit Prepar3D -> Yes -> NO Crash
Exit (from fully loaded Prepar3D Default Scenario) -> Yes -> CRASH
Difficult for me to draw any definitive conclusions from these results other than the fact that the sim does not crash while exiting from the Prepar3D Scenario screen.
Regards,
Mike
-
I'm sorry, but I don't understand what do you mean with Exit "from fully loaded Prepar3D Default Scenario", opposite to just "Exit".
-
I'm sorry, but I don't understand what do you mean with Exit "from fully loaded Prepar3D Default Scenario", opposite to just "Exit".
Hi Umberto,
Each EXIT test cycle involved shutting down the sim in 3 ways:
1. From the Prepar3D Scenario Startup screen (the screen that appears first during the inital load allowing configuration of your flight)
2. Scenario - End Scenario
3. Scenario - Exit
In the case of 2 and 3 I'm sitting in the default Raptor, rwy 19 at Eglin AFB (KVPS) after the Prepar3D Default flight has loaded.
Regards,
Mike
-
I'm sorry, but I don't understand what do you mean with Exit "from fully loaded Prepar3D Default Scenario", opposite to just "Exit".
Hi Umberto,
Each EXIT test cycle involved shutting down the sim in 3 ways:
1. From the Prepar3D Scenario Startup screen (the screen that appears first during the inital load allowing configuration of your flight)
2. Scenario - End Scenario
3. Scenario - Exit
In the case of 2 and 3 I'm sitting in the default Raptor, rwy 19 at Eglin AFB (KVPS) after the Prepar3D Default flight has loaded.
Regards,
Mike
Mike thank you for doing this. I removed fsdt airports and gsx from my p3d until the crashing is fixed.
-
Mike thank you for doing this. I removed fsdt airports and gsx from my p3d until the crashing is fixed.
I’m certainly getting a sense of what Developers must experience with the constant loading and unloading of the sim as they test any changes made! Can be quite tedious and very time consuming, but I do enjoy a challenge! While I’m not involved in any coding changes I’m quite happy to help with testing.
I don’t think it is really necessary to remove these products. You can still enjoy what they have to offer so long as you accept the sim is likely to crash on exit knowing that no harm will result from allowing this aberrant behaviour. Hopefully we will have a solution soon and hopefully LM will stay on board until that solution is found.
Regards,
Mike
-
Mike thank you for doing this. I removed fsdt airports and gsx from my p3d until the crashing is fixed.
I’m certainly getting a sense of what Developers must experience with the constant loading and unloading of the sim as they test any changes made! Can be quite tedious and very time consuming, but I do enjoy a challenge! While I’m not involved in any coding changes I’m quite happy to help with testing.
I don’t think it is really necessary to remove these products. You can still enjoy what they have to offer so long as you accept the sim is likely to crash on exit knowing that no harm will result from allowing this aberrant behaviour. Hopefully we will have a solution soon and hopefully LM will stay on board until that solution is found.
Regards,
Mike
I have unstable flights if I do not remove all the fsdt products. Crashing, freezing, in-flight, not only on exit.
5 completed flights uneventful after removing fsdt.
-
I'm sorry, but I can only repeat and confirm the crash on exit is fixed. This has been confirmed even by LM, which helped us finding the cause.
If you have other issues, then they are NOT caused by GSX or any FSDT product. There was another thread which some users reported low fps with GSX installed, which I could replicate, and it really looked like a problem caused by GSX, since it seemed to go away by disabling the Addon Manager addon.
However, from the latest posts, it turned out to be an incomplete upgrade from 4.1 to 4.2, for example updating the client without updating the content.
Fact that removing our software seems to "fix" the problem, it's only because you don't have other addons that use advanced parts of the SDK which have been updated recently and might not work correctly with just the client or with a failed/incomplete update.
-
I'm sorry, but I can only repeat and confirm the crash on exit is fixed. This has been confirmed even by LM, which helped us finding the cause.
Fact that removing our software seems to "fix" the problem, it's only because you don't have other addons that use advanced parts of the SDK which have been updated recently and might not work correctly with just the client or with a failed/incomplete update.
Well, speaking as one who has a full and stable installation of Prepar3D 4.2 I find that response to be very disappointing and is threatening to undermine my faith in the product. It is clear to me that something is still happening between Prepar3D and the FSTD Addon Manager during exit, causing Prepar3D to crash, and I feel I have done my best to demonstrate that this is indeed the case. However, it appears that the Developer and LM beg to differ so it looks like we are on a hiding to nothing with very little likelihood of finding a resolution.
Unless others feel inclined to chip in with their experiences and/or there is a change of stance on this matter by the Developer, I don’t believe I have anything more to contribute to this now unsatisfactory and unproductive thread. Meantime, I have been maintaining my Prepar3D installation in the requested bare bones state required for troubleshooting purposes. This seems to me to be the least I can offer in view of the time and work spent to date testing for Umberto. However, such patience is finite.
Mike
-
I'm sorry, but I can only repeat and confirm the crash on exit is fixed. This has been confirmed even by LM, which helped us finding the cause.
Fact that removing our software seems to "fix" the problem, it's only because you don't have other addons that use advanced parts of the SDK which have been updated recently and might not work correctly with just the client or with a failed/incomplete update.
Well, speaking as one who has a full and stable installation of Prepar3D 4.2 I find that response to be very disappointing and is threatening to undermine my faith in the product. It is clear to me that something is still happening between Prepar3D and the FSTD Addon Manager during exit causing Prepar3D to crash and I feel I have done my best to demonstrate that this is indeed the case. However, it appears that the Developer and LM beg to differ so it looks like we are on a hiding to nothing with very little likelihood of finding a resolution.
Unless others feel inclined to chip in with their experiences I don’t believe I have anything more to contribute to this somewhat unsatisfactory and unproductive thread.
Mike
I seem to be experiencing this same issue on what was a new/clean install of 4.2 which I purchased on 2018 March 14. Previous to today I never noticed this behavior - I had reinstalled Addon Manager on May 17 to chase some issues I had been having in FSX, so I presume that is where the problem probably originated (I had last used P3D4 on May 14). I had not run Live Update between that initial install of Addon Manager in mid-March (which I had re-downloaded for the fresh install, so it should have been a version current for that date) through May 17. Such behavior makes it seem as though some change between March and May is causing this problem.
I can't confirm it is having any other effects other than the crash on termination, but I did come home earlier this evening to find that a paused flight (PMDG 777) had suspiciously crashed without so much as an error dialog (never had that happen before), and it was the attempted diagnosis of that which ultimately turned me onto this issue - which I discovered upon "properly" exiting P3D4. I'm not trying to imply there's any causation or correlation here - seems impossible to tell at this point - just background info.
-
We know precisely what caused the problem in the update that happened around March. And that one IS fixed in the current Live Update, this is really not open to any discussions.
Note that, I'm ONLY referring to the silent crash on exit with NO error messages, which can only be visible as an Event in the Event Viewer as an API.DLL crash. This is the only thing this thread is about, and is the only thing the current update was supposed to fix (in addition to other minor fixes in GSX procedures), and it's 100% confirmed to be fixed.
So, if you still have THAT specific crash, the only possible reason is that you haven't applied the latest Live Update yet.
If you have OTHER crashes or instabilities, which don't manifest as API.DLL silent crashes on the Event Viewer, than please open a new thread, describing the problem, and we'll see if *THAT* one has anything to do with our software.
-
Hi Umberto,
No other crashes or instabilities whatsoever and, yes, I did apply the last update as I believe I stated earlier in this thread.
However, in case another update has been released since I’ll try running the FSDT Live Updater again.
I appreciate how frustrating this must be for you, Umberto, particularly as your experience is so different. Nevertheless,there are some users, like me, who still have the problem and may feel they are being stone walled by FSDT GSX Support. That too is frustrating!
Surely there must be some other way of isolating the cause in our installations? For example does the Addon Manager create any log files? Are there any tools we can employ to monitor what is happening other than the Windows Event Viewer?
Believe me, I am just trying to be helpful.
Regards,
Mike
-
Surely there must be some other way of isolating the cause in our installations? For example does the Addon Manager create any log files?
I'm sorry but, as I've said, the one and only possible reason why you have an silent API.DLL crash on exit (only), which disappears if you disable the Addon Manager, is because you still have the previous version installer, so you haven't done the Live Update, or your antivirus blocked it, so you are stuck with the old executable. THIS (and ONLY THIS) crash is fixed now.
It's either this, or you are having another crash, one that is not likely caused by the Addon Manager, even if might look similar. In this case, test if the crash happens with all the other addons (except the Addon Manager), are disabled.
-
The api.dll crash did continue to occur after running the Live Update, I don't use antivirus software, and my bglmanx64.dll was updated to 4.5.0.3. But perhaps there's something else going on so I'll do a clean download and reinstall of Addon Manager later today and see if that does the trick.
-
I can only repeat and confirm, I cannot reproduce anymore the API.DLL crash on exit with the current version of the Addon Manager, while I was able to reproduce it (100% of the times), with the previous version.
As I've said in my previous message, you should try disabling all other modules, except the Addon Manager, to confirm this is the *same* crash which has been discussed here, which is now fixed.
-
As I've said in my previous message, you should try disabling all other modules, except the Addon Manager, to confirm this is the *same* crash which has been discussed here, which is now fixed.
And as one who has done precisely that, here are my latest results:
Addon Manager folder permissions edited to allow Modify and Write.
ESET NOD 32 disabled temporarily (in fact the Addon Manager folder has been included under
Exclusions).
FSDT Live Update executed (Run as administrator: NO.
Noted at start bglmanx.dll and bglmanx64.dll were both downloaded so hopes
for a favourable outcome were raised!
ESET NOD32: PROTECTION RE-ENABLED
EXIT RESULTS:
Prepar3D default flight fully loaded
Note: Currently Prepar3D v4.2 is NOT being Run as administrator. This will change when FSLabs is reactivated.
'X' -> Yes -> NO Crash
Scenario -> End Scenario -> Exit Prepar3D -> Yes -> CRASH
Scenario -> [b}Exit[/b] -> Yes -> CRASH
Scenario Startup screen: 'X' -> Yes -> NO Crash
SYSTEM RESTART
EXIT RESULTS:
Prepar3D default flight fully loaded
'X' -> Yes -> NO Crash
'X' -> Yes -> NO Crash
'X' -> Yes -> NO Crash
'X' -> Yes -> NO Crash
Scenario -> End Scenario -> Exit Prepar3D -> Yes -> NO Crash
Scenario -> End Scenario -> Exit Prepar3D -> Yes -> CRASH
Scenario -> End Scenario -> Exit Prepar3D -> Yes -> NO Crash
Scenario -> End Scenario -> Exit Prepar3D -> Yes -> CRASH
Scenario -> End Scenario -> Exit Prepar3D -> Yes -> CRASH
Scenario -> End Scenario -> Exit Prepar3D -> Yes -> CRASH
Scenario -> End Scenario -> Exit Prepar3D -> Yes -> CRASH
Scenario -> [b}Exit[/b] -> Yes -> NO Crash
Scenario -> [b}Exit[/b] -> Yes -> NO Crash
Scenario -> [b}Exit[/b] -> Yes -> CRASH
Scenario -> [b}Exit[/b] -> Yes -> NO Crash
Scenario -> [b}Exit[/b] -> Yes -> NO Crash
Scenario -> [b}Exit[/b] -> Yes -> NO Crash
Scenario Startup screen: 'X' -> Yes -> NO Crash
Scenario Startup screen: 'X' -> Yes -> NO Crash
I think, by now, everyone should be able to draw their own conclusions. Something may have changed with the 'latest' FSDT Live Update since I am having more success than previously. However, if my results have any value, then those experiencing these 'crashes on exit' would be well advised to exit the sim meantime by avoiding the Scenario -> End Scenario and Scenario -> Exit options although you might be lucky when choosing the latter.
Mike
-
Addon Manager folder permissions edited to allow Modify and Write.
This is NOT required and, it would be best if you don't touch anything. Are you assuming our installer didn't set the proper permissions ? It surely does so, please, don't add extra unnecessary steps, made assuming there's something "wrong" with the software.
Scenario -> End Scenario -> Exit Prepar3D -> Yes
Since, according to your test, this sequence was the one that gave you the highest chance of a crash on exit, I tried it right now, 7 times in a row (exactly like you did) and the result was...
7 "NO CRASH" so, 0 crashes over 7 tries.
I tried starting from a random flight I had set as default, and with the Default P3D flight with the F22, no difference. No crashes in both cases.
Something may have changed with the 'latest' FSDT Live Update since I am having more success than previously.
Nothing has changed in the latest update. I only tried to trick the Live Update server into forcing a download, by changing the timestamp of the digital signature, so the file would by different, and be surely downloaded, in order to exclude the chance that for some reason the server didn't supply the latest file.
But otherwise it's unchanged.
-
Addon Manager folder permissions edited to allow Modify and Write.
This is NOT required and, it would be best if you don't touch anything. Are you assuming our installer didn't set the proper permissions ? It surely does so, please, don't add extra unnecessary steps, made assuming there's something "wrong" with the software.
Nothing has changed in the latest update. I only tried to trick the Live Update server into forcing a download, by changing the timestamp of the digital signature, so the file would by different, and be surely downloaded, in order to exclude the chance that for some reason the server didn't supply the latest file.
But otherwise it's unchanged.
I am assuming nothing, believe me. I did this simply because I knew it was unlikely to do harm and in the hope that it might help to ensure the Live Updater would install all files intact. Easy enough to revert back.
Good to know that nothing has changed in the latest update. Thanks!
You emphasise the importance of allowing installers to set up the necessary permissions and I agree one hundred percent. However, I have shown that FSLabs is interfering with this process and, if active, will reset the Prepar3D executable to Run as Administrator (with a necessary restart as there is no way to counter this) during the sim loading phase. Since making that discovery I have been running with that box unchecked and ALL Addons disabled (except for the Addon Manager/Couatl) which has preserved that condition. Again, please see my previous posts as this has been mentioned a few times already.
So, we are left with an unsatisfactory situation where our experiences are differing. We still do not know why this is the case and, without access to appropriate debugging tools there is no way I can move forward on this. Fortunately my latest series of tests has revealed alternative exit options which are more likely to succeed.
If no further help is forthcoming then I suggest we leave it at that.
Thanks for your time and the attention given to this issue. It has been a very time consuming exercise with, arguably, little reward.
It’s usually difficult to know exactly why a thread attracts so much interest, as the ever increasing Views count for this topic is suggesting. Either it’s to learn about the solution (attaching **SOLVED** to the subject title early on would do this), casual interest or simply to see how this troubleshoot pans out. Who knows! A lack of other contributors to the thread does not necessarily imply that the majority of users are without issues and remain happy with things as they are.
Regards,
Mike
-
However, I have shown that FSLabs is interfering with this process and, if active, will reset the Prepar3D executable to Run as Administrator (with a necessary restart as there is no way to counter this) during the sim loading phase.
I made all my test running As Administrator because, even if it's not the default way to run the sim, many users (willingly or not), run it that way and, initially, it *seemed* the Administrator mode could be the cause.
It's not. It was something else entirely, which was totally related to something in our code, which simply cannot happen anymore, because that code has changed.
A lack of other contributors to the thread does not necessarily imply that the majority of users are without issues and remain happy with things as they are.
But it doesn't necessarily imply the opposite...
-
The problem persists with me as well, even after removing all traces of Addon Manager and installing with newly downloaded installers. Unchecking "run as admin" on P3D4 has been good for a couple crash-free exits but it's not very consistent. I also tried reinstalling Addon Manager back to its default (Program Files x86) folder and that helped once or twice - I originally had it installed to a second SSD with other add-ons in order to avoid the Windows nanny-ing known to occur in the "Program Files" folders even with UAC disabled.
-
ctd free week of flying with all fsdt products uninstalled. Checking back here for a solution hopefully soon
-
ctd free week of flying with all fsdt products uninstalled. Checking back here for a solution hopefully soon
We already provided with the solution, otherwise this thread wouldn't be flagged as "solved".
-
ctd free week of flying with all fsdt products uninstalled. Checking back here for a solution hopefully soon
We already provided with the solution, otherwise this thread wouldn't be flagged as "solved".
It is fixed for my p3d thank you
-
close to 2 weeks crash free flying, gsx installed yesterday, device hung error in cruise after 4 hrs today.
-
close to 2 weeks crash free flying, gsx installed yesterday, device hung error in cruise after 4 hrs today.
I'm sorry, but the "DXGI device hung" error is only related to issues video drivers, it cannot possibly have anything to do with GSX ESPECIALLY when flying, since there are NO GSX objects created (to dispel the chance something like a corrupted texture/model could have caused it), it was just a coincidence that happened when you reinstalled GSX.
When flying, no GSX objects are created, and the only thing it does, is to check your position in case you are close to an airport so, NOTHING related to graphic.
-
I have little patience for testing and tweaking I removed all scenery and apps that are unrelated to my current flight. I will reinstall GSX and the FSDT scenery after some flights in this state after it proves to be stable.
-
I want to turn off EAX sound is that possible. It is enabled I read in the GSX log files
-
GSX uses whatever capabilities your audio card has and which of them have been exposed to their own OpenAL implementation.
Since we DO 3D positional sound, if your audio card has hardware support for EAX, GSX will use it automatically and cannot do otherwise, since the available capabilities of the OpenAL implementation (which can be either hardware of software, depending on the audio card) are exposed by the audio driver.
But why you want to to turn off EAX in the first place ? We require it for many things, both positional audio but also to get distance attenuation. If you could hypothetically turn it off, every sound would come from dead center, and will always sound the same level, regardless of the distance from the observer, which was the main point of using OpenAL to begin with.
-
Hi guys, I have a same problem. Since last update via Live Update I have constant crash on exit (api.dll). I have latest version of addon manager ver. 4.5.0.2. But what is even worse, I have slient crashes during flight without any error message since than. I tired to run Live Update several times but it didnt help.I checked bglmanx.dll as well as bglmanx64.dll and I have latest versions.
Only solution for me is to disable addon manager, tested several flights and NO crash during a flight, NO crash on exit.
So unfortunely, I have to live without those great addons as GSX etc.
Jozef
-
I'm sorry, but I can only confirm the API.DLL is fixed in the latest Update. I suggest waiting also for the next P3D patch, because it's possible this might be caused by a bug in the 4.2 version of the SDK.
-
Hi guys,
I uninstaled all fsdt products and deleted all folders including addon manager and than I instaled again all products, since than, no crashes. Just try, good luck.
mefisssto
-
Again, I can only confirm the API.DLL is fixed in the latest Update. I suggest waiting also for the next P3D patch, because it's possible this might be caused by a bug in the 4.2 version of the SDK.
-
i'm still getting this crash on exit every time if i enable any FSDT product. I am on Windows 7 64bit. The P3d V4.3 is just around the corner, hopefully this is going to fix it
-
Continuing to get these errors myself, probably 90% of P3D exits and today I had a "quiet" CTD that actually did leave a log in Event Viewer (usually it doesn't leave one of those) quoting API.dll as the culprit. Will advise once 4.3 comes out. I might just have to stick with the Aerosoft Buses in FSX for the mean time.
We're probably close enough to release that it won't be a big issue, but is there any way to get a hold of the pre-May versions with which these issues didn't seem to happen?
-
I deleted the addon manager directory
removed all the addon folders for gsx and fsdt products
and ran the installers again after virtuali said they fixed it
I do not crash on exit. I am using windows 10
clarifying you should download the latest installers again after uninstalling the files
-
I deleted the addon manager directory
<snip>
clarifying you should download the latest installers again after uninstalling the files
I did all of the above at least twice but with no favorable result - running Win7 x64. Maybe the OS? Or maybe your mileage varies. Either way it's not too much of a yank to wait for 4.3 if that does indeed solve the problem universally. Still makes me wonder why it suddenly went bad in 4.2 and a rollback was not available, but whatever.
-
P3D upgraded to 4.3 and random ctd, nvidia divice hung errors, p3d disappearing, is back! Liveupdate ran as admin so I have the latest gsx and other updates. But P3D is not stable, again. I am removing all fsdt products and trying next week if that brings stability back
-
The frozen moonwalking marshaller is back. The gsx version for p3d4.3 feels like a step back.
-
I can't see any "frozen" marshaller, no ctd, no pauses, no freezes and P3D 4.3 is very stable, and it's probably the best version to use GSX with.
Of course, if your system has issues like video driver problems (nvidia divice hung errors), usually caused by wrong settings, wrong tweaks, too high settings, etc. the sim will suffer and, of course, if the sim has issues, all addons that goes with it will not work well, including GSX.
-
I can't see any "frozen" marshaller, no ctd, no pauses, no freezes and P3D 4.3 is very stable, and it's probably the best version to use GSX with.
Of course, if your system has issues like video driver problems (nvidia divice hung errors), usually caused by wrong settings, wrong tweaks, too high settings, etc. the sim will suffer and, of course, if the sim has issues, all addons that goes with it will not work well, including GSX.
Like last time I had crashes, removing GSX and all FSDT products my P3D 4.2 was stable able to fly 2-3 long hauls without ever quitting the sim.
-
Like last time I had crashes, removing GSX and all FSDT products my P3D 4.2 was stable able to fly 2-3 long hauls without ever quitting the sim.
We demoed GSX boarding/deboarding passengers (so it was doing even more than the curent release version) to the LasVegas Flightsimexpo for 10 hours at day, with not a single crash, to hundreds of people so no, it's not GSX.
There's a thread about crashes when flying, which some users assumed to be caused by GSX, but that's only because GSX constantly reads the nearby airports and navaids, but it's the SIM itself which is crashing, because of problems in the navigation database and, in one case, one of the affected users reported it was caused by having updated the navigation database with a 3rd party addon, and THAT was the real cause. The only thing GSX does, is to call a function provided by the sim to read that data so, clearly, it's the sim that gets confused by itself when calling its own function.
Just to indicate an example of a crash that you can be easily mislead is "caused" by GSX (because "it goes away without GSX"), when in fact the real cause is something else.
-
Hi Umberto,
I've now moved up to Prepar3D v4.3 (Client, Content and Scenery) and, sadly, I'm afraid the problem is still there!!
The reported error is different, however, in that the faulting module is now ntdll.dll
-
I've now moved up to Prepar3D v4.3 (Client, Content and Scenery) and, sadly, I'm afraid the problem is still there!!
No, it's not.
The reported error is different, however, in that the faulting module is now ntdll.dll
That's why I say it's not.
This thread was about the API.DLL crash on exit, which wasn't visible, unless you went into the Windows Event Viewer. That's the only kind of crash on exit that has been discussed here, and that IS fixed, because I could reproduce it 100% of the times, asked LM for help, found the cause, and released a fix.
Your report is a totally different issue, so it's very confusing have it posted here, in a thread that has already been marked as solved, because IT IS solved.
So, please, post a new thread, with a proper title, such as "ntdll crash" and describe your error. I'm quite sure the problem is NOT GSX, please read my previous reply about a possibly corrupted navigation database, which would make the sim crash when asking the sim about it.
But please, don't reply here, and open a new thread. If it's ok for you, we might also arrange a Teamviewer session early next week, so I could have a look at your system.
-
Hi Umberto,
Okay, I take your point and can only apologise for inadvertently introducing some confusion into this thread. However, and to be fair, the title of the thread only mentions “addon Manager crash on exit p3d 4.2”. There is no mention of api.dll although the thread did focus on this faulting module and you found a solution which, and unfortunately, was not mirrored on my system and those of several others who have posted.
As I stated, I have moved on to Prepar3D v4.3 in the earnest hope that the api.dll issue was resolved and, indeed, that does appear to have been the case as my crashes on exit of the sim no longer implicate this file but, instead, that of another. So, I submit to that extent at least, my post regarding faulting module ntdll.dll remains perfectly valid within the context of this thread. Okay, perhaps I’m being overly pedantic but, hopefully, you see where I’m coming from and why I felt it was reasonable, in the first instance, to continue posting in this thread.
Your kind offer to involve me in a TeamViewer session sounds interesting. I have no experience of using this facility so some guidance will be needed. Should I go ahead and install the TeamViewer App and what information is needed to facilitate your access to my PC? I reside in Scotland, UK. Perhaps we should continue this conversation via PM?
Meantime, I’ll try uninstalling/reinstalling GSX and see whether this makes any difference.
Best regards,
Mike
-
There is no mention of api.dll although the thread did focus on this faulting module and you found a solution which, and unfortunately, was not mirrored on my system and those of several others who have posted.
Nobody that posted here said they STILL have the API.DLL crash on Exit. Some said that after our fix, there were no crash on exit anymore, some said they had OTHER crashes, like nvida device hung etc, and of course, none of these crashes have been proven to be caused by GSX.
Our fix fixes ONLY the one crash which WAS caused by GSX, and it was the API.DLL crash on exit. It doesn't magically fix every other crash of the sim not caused by our software.
So, I submit to that extent at least, my post regarding faulting module ntdll.dll remains perfectly valid within the context of this thread. Okay, perhaps I’m being overly pedantic but, hopefully, you see where I’m coming from and why I felt it was reasonable, in the first instance, to continue posting in this thread.
I don't agree with you, but that's not the issue.
Your kind offer to involve me in a TeamViewer session sounds interesting. I have no experience of using this facility so some guidance will be needed. Should I go ahead and install the TeamViewer App and what information is needed to facilitate your access to my PC? I reside in Scotland, UK. Perhaps we should continue this conversation via PM?
Yes, of course we should.
-
Hi Umberto,
An interesting development at my end: I stripped Prepar3D v4.3 back to a bare bones installation. All Addons disabled (with the exception of the FSDT Addon Manager), everything in the dll.xml and exe.xml files disabled and fresh scenery.cfg and terrain.cfg files created. The latter has been modified only by ORBX FTXCentral 3 and the Black Marble NG Control Panel.
The good news: the ntdll.dll faulting module error has gone!
The not so good news: the api.dll faulting module error has returned and is occurring during all 3 Exit routes as described previously.
I’ll wait for you to get in touch. Meantime I’ll leave my basic configuration as is. One good thing - the sim loads so much more quickly..lol!
Regards,
Mike
-
The good news: the ntdll.dll faulting module error has gone!
This clearly proves the problem was never caused by our software, which of course I was quite sure of.
The not so good news: the api.dll faulting module error has returned!!
This, instead, doesn't prove THIS api.dll is caused by our software unless, of course, you are still with the old version, which DID caused the (invisible) crash in the API.DLL ON EXIT ONLY, and this is confirmed to have been FIXED in the current version which is online now.
The API.DLL can be caused by so many different causes so, for example, even an airplane gauge using Simconnect can cause it, even if you removed all modules, because that won't necessarily require an addon module to work.
Have you tried resetting the Prepar3d.cfg file as well ? Maybe a bad setting from having installed another addon is causing problems, so it won't matter if that addon is now disabled.
-
Have you tried resetting the Prepar3d.cfg file as well ? Maybe a bad setting from having installed another addon is causing problems, so it won't matter if that addon is now disabled.
Hi Umberto,
No, I confess I didn’t consider that possibility. I will do so and try again with the newly created default file before modifying anything within that file.
Regards,
Mike
-
Have you tried resetting the Prepar3d.cfg file as well ? Maybe a bad setting from having installed another addon is causing problems, so it won't matter if that addon is now disabled.
Hi Umberto,
Using newly created default Prepar3D.cfg without any modifications.
Sadly, same result in all 3 Exit route cases: faulting module api.dll
In case of 'End scenario' and 'X' P3D crashed every time.
'Exit' was less consistent: sometimes it did crash and sometimes it did not.
I've attached the Report.wer file (retrieved following exit by 'X') in case the content is of any help.
Regards,
Mike
-
Sadly, same result in all 3 Exit route cases: faulting module api.dll
In case of 'End scenario' and 'X' P3D crashed every time.
As you can see, it doesn't happen here. Neither a visible crash, nor an invisible crash only seen in the Event Viewer.
-
The api.dll crash on exit persists for me as well - even in an extreme scenario: Fresh install of P3Dv4.3 and NO 3rd party content of any type installed aside from GSX and KJFK (and SODE, which was installed through the FSDT installer). The only modifications to Prepar3D.cfg that I have made are those necessary to display full screen on my larger monitor (set through the Options-Display dialog; the crash would also occur on a completely "pure" cfg in attempts before the reinstall anyway).
The crash occurs with only GSX installed and with only KJFK installed, which would seem to indicate it's not being caused by either of those packages but rather Addon Manager itself.
I've had the crash on all but three exits out of at least 15 tries. Interestingly one successful exit occurred immediately after unregistering SODE, another immediately after disabling the Couatl live update, and the last immediately after updating my graphics drivers (which were only 2 months old and who knows if I won't have to roll back for some reason). On all subsequent exits, regardless of those settings, it has crashed reliably on every other attempt. The only time it does not reliably crash (or seemingly at all) is when exiting from the opening scenario screen.
Short of a hardware or Windows issue that has never revealed itself in any other way, I'm a little thrown for how these crashes cannot possibly be caused either by Addon Manager or by some persistent bug in P3D4 which Addon Manager is exposing.
Is there no way to get a copy of the files that were current as of March, unless such would cause more consequential problems?
-
Short of a hardware or Windows issue that has never revealed itself in any other way, I'm a little thrown for how these crashes cannot possibly be caused either by Addon Manager or by some persistent bug in P3D4 which Addon Manager is exposing.
The missing keyword here is "on YOUR system" because, as of today, there are only two users, you and Cruachan that still reports this issue. As I've said in other threads, I would like to have a look at your system by doing a Teamviewer session. PM to arrange this.
-
Heads up guys, it seems the rules have been changed...lol!
Hitherto we have understood and been advised to strip everything back until the cause of an issue is identified. In the past this guidance seems to have worked well enough and Sabertooth78 and I have, with diligence, followed this diagnostic process. However despite our best efforts, it seems the goal posts have now been changed! We have both confirmed that the problem goes away when the FSDT Addon Manager is disabled and yet Umberto appears to be in denial over our findings.
To assert that we are the only users reporting this problem is at best shaky. It seems doubtful that our individual setups are unique in some strange way, but we have gone along with this supposition in the hope that Umberto would help us isolate what is responsible. Clearly he must have some ideas as he is suggesting having TeamViewer sessions to allow him to examine our installations. Why then can he not air his thoughts publically to allow us to conduct our own investigations?
We cannot be certain, but there is every likelihood that other users may be affected by this and are watching this thread to see how it all pans out. Just because they don’t post does not mean they are not there....waiting.
Mike
-
Heads up guys, it seems the rules have been changed...lol!
No, they haven't.
Hitherto we have understood and been advised to strip everything back until the cause of an issue is identified. In the past this guidance seems to have worked well enough and Sabertooth78 and I have, with diligence, followed this diagnostic process. However despite our best efforts, it seems the goal posts have now been changed! We have both confirmed that the problem goes away when the FSDT Addon Manager is disabled and yet Umberto appears to be in denial over our findings.
Yes, this is still valid. However, I would first like to check if *everything* has *really* been disabled. Which is why, I asked for a Teamviewer session, which as of today, you still have failed to reply to.
To assert that we are the only users reporting this problem is at best shaky.
This is clear fact. That doesn't obviously mean I'm sure nobody else still has the problem, but surely nobody except you too is still reporting it, after the May 22th fix. The "nobody else except you two has reported it", doesn't mean anything more than that.
Why then can he not air his thoughts publically to allow us to conduct our own investigations?
Because until I'm able to reproduce it, I cannot do anything about it. So, the TM session is obviously a way for me to reproduce it, on YOUR system, since I'm obviously unable to reproduce on mine and, of course, on any other system of everybody else working at FSDT.
I'm waiting for your PM to arrange an TM session.
-
Hi Umberto,
My sincere apologies if I seem to be coming on a bit strong, but it’s just a mark of my frustration over this matter. Your patience and persistence is admirable as is your apparent unwillingness to lock this thread until we find the solution, and I thank you for that.
I admit I may appear stubborn at times and can spend inordinate amounts of time working a problem before eventually conceding defeat. However, this aspect of troubleshooting where an application can reveal an issue, without actually being the root cause, is new to me and has been quite difficult to accept. I’m far from being the expert in this field so feel I should be acknowledging that your convictions may well prove to be correct after all.
I have no objections to having a TeamViewer session. Indeed, I did ask in an earlier post (either here or at AVSIM) for some guidance regarding what I needed to do in the way of preparation and any info (e.g. IP Address) required to facilitate your access to my PC. I may have misunderstood how this works and had assumed that you would get in touch with me to arrange a time convenient to us both.
When you stated that you intended to use the TeamViewer session to check that everything has really been disabled I wondered why you seemed unwilling to elaborate about this on the forum and we could check for ourselves. DLL.xml and EXE.xml (AppData and ProgramData) currently have all items disabled, All Add-ons, with the exception of SODE (installed by the GSX installer) and FSDT Addon Manager have been disabled in sim, Prepar3D.cfg is default bar a few graphic changes to suit my display, Scenery.cfg is default plus 3 Black Marble entries (testing a few things for Chris Bell). What else should I be checking?
If requested, I can send you all the relevant files for you to examine.
Regards,
Mike
-
My sincere apologies if I seem to be coming on a bit strong, but it’s just a mark of my frustration over this matter. Your patience and persistence is admirable as is your apparent unwillingness to lock this thread until we find the solution, and I thank you for that.
Same here. I sent a PM earlier, but my outbox isn't showing it so I have no idea if it sent. Long story short, I'm not against participating in a session but at the same time I'm not sure what value such intervention could provide. Same situation as Cruachan, with the added nuance of a completely fresh installation. My schedule is also a bit restricted - especially end-of-week. At this point I'm left with tweaking BIOS settings to hope for the stupid issue to go away, or that a future Live Update mysteriously fixes it.
In any event I'm of two minds on this issue. Thinking in my day job mindset as an engineer, I'm not usually the one to have such problems nor do I often have to concede defeat. On the other hand, I just want to use the darn thing for what it's for - flying. The crash on exit doesn't bother me so much from an operational standpoint (in all reality it's quite inconsequential), it's just that I see that as a potential harbinger of other problems (i.e. well, it's obviously causing an issue somewhere, so is this going to manifest itself somewhere else down the line?) I'm an engineer - I abhor loose ends. As I've mentioned before, I've had occasional seemingly random crashes periodically, so in my mind they could be related. Yes, I know there is no evidence to prove it. But neither is there evidence to disprove it. That's what's so vexing and frustrating about it. (I say I don't usually have tech problems, but in another example to the contrary, I think I'm the one-in-a-million case where I still maintain an FSX installation that I would contend is still more stable than P3D4. At least when FSX does crash it's usually apparent why.)
If nothing else, I was expecting a complete system reinstall once I no longer require FSX, so that would theoretically clear up the hardware/Windows question. Not quite ready for that yet. I'm actually contemplating building a new rig anyway, so who knows.
UPDATE: I reset my BIOS to "Optimized Defaults" (I typically run a modest overclock) and as seems to be the pattern, first time did not CTD but all subsequent exits bombed out. I'm sure it's coincidence but it's almost as if there's some kind of cache somewhere getting corrupted.
-
I have no objections to having a TeamViewer session. Indeed, I did ask in an earlier post (either here or at AVSIM) for some guidance regarding what I needed to do in the way of preparation and any info (e.g. IP Address) required to facilitate your access to my PC. I may have misunderstood how this works and had assumed that you would get in touch with me to arrange a time convenient to us
Just PM-me about this. PM-me = Send me a Private Message on the forum.
-
Same here. I sent a PM earlier, but my outbox isn't showing it so I have no idea if it sent.
The outbox will not refresh until I read your PM, which I did only now, since we obviously live in different timezones...
UPDATE: I reset my BIOS to "Optimized Defaults" (I typically run a modest overclock) and as seems to be the pattern, first time did not CTD but all subsequent exits bombed out. I'm sure it's coincidence but it's almost as if there's some kind of cache somewhere getting corrupted
The problem might be related to the video card so, acting on the bios might change something related to it.
-
I do have the ASUS-supplied "GPU Tweak" program which I was using for a short time until it once caused the whole system to suddenly reboot and I suspected it also may have been causing instabilities in P3D, though I thought I had cleared that back to defaults and I haven't used it since. In any event I wasn't getting these CTDs, though, but I've seen more inexplicable problem causers and solutions so it wouldn't surprise me. I'll play around with that this evening and see what if anything happens.
-
I installed P3D 4.3 from scratch and lowered the autogen radius slider from the max and have not had a crash. I read posts on avsim about the autogen slider causing Nvidia device hung messages. The crash on exit was fixed in 4.3 and auto updating gsx. Thank you Virtuali.
-
I installed P3D 4.3 from scratch and lowered the autogen radius slider from the max and have not had a crash. I read posts on avsim about the autogen slider causing Nvidia device hung messages. The crash on exit was fixed in 4.3 and auto updating gsx. Thank you Virtuali.
That didn't work for me, as I had already set that particular setting to medium.
The problem might be related to the video card so, acting on the bios might change something related to it.
In other news, I upgraded my video card; I had been thinking about that for a while anyway. Call it the first piece of the new system. That didn't help either! (But so far the performance gain is, shall I say, significant. I hestitate to say stunning when the configuration isn't fully rebuilt.)
That said, I also tried lowering ALL settings down to minimum. Basically now it looks like a FS 5. That didn't help.
Annoyed, I decided to move full speed ahead with the rebuild. Lo and behold, somewhere along the way, I got 2-3 exits before it reappeared. We shall see...
-
I decided to move full speed ahead with the rebuild. Lo and behold, somewhere along the way, I got 2-3 exits before it reappeared. We shall see...
Hi Sabretooth78,
That alone should be telling us something. I suspect it’s a timing issue, i.e. how long it’s taking for certain modules to unload during the exit phase. I have experienced this behaviour as well from time to time where Prepar3D exits gracefully, but with the next attempt it quickly reverts back to the crash on exit with api.dll being the faulting module. However, I have never witnessed two or more consecutive graceful exits while the FSDT Addon Manager is running.
I have decided I will go ahead with Umberto’s kind offer to engage in a TeamViewer session. Never done this before so I have been doing some homework to familiarise myself with the process. I must say I’m impressed with how this works. TeamViewer needs to be installed and running on both computers. After the weekend I will PM Umberto and provide him with an ID for my PC (created by the App) and the necessary password. Thereafter access should be quite straightforward. I discovered there is a TeamViewer App for iOS devices so installed it on my iPad. Works a treat! The only slight downside is that to see the whole desktop you really have to set the resolution to match the resolution of your Monitor’s screen. Everything then appears quite small albeit sharpness is still maintained on the iPad screen. Selection with your finger then becomes cumbersome and often inaccurate. However there is an option to use the target PC’s mouse pointer and this can be manipulated accurately by finger movement from anywhere on the iPad screen (it’s not necessary to touch the on-screen pointer). You can zoom in and out, double tap to execute, double tap and hold to move a window and so on....pretty much everything is there and can be easily managed on the iPad. I must say I was pleasantly surprised by the responsiveness - Prepar3D loading and exiting mirrored what I have been seeing on my Monitor and all this from the comfort of my armchair in front of the tele! Amazing!
Regards,
Mike
-
That alone should be telling us something. I suspect it’s a timing issue, i.e. how long it’s taking for certain modules to unload during the exit phase. I have experienced this behaviour as well from time to time where Prepar3D exits gracefully, but with the next attempt it quickly reverts back to the crash on exit with api.dll being the faulting module. However, I have never witnessed two or more consecutive graceful exits while the FSDT Addon Manager is running.
I had a somewhat productive TM session with Umberto this morning - "somewhat" in the sense that he believed he had diagnosed the problem but wasn't able to fix it. Anyway, he suspected it was due to running Windows 7. While I was anticipating an eventual upgrade to Windows 10, I decided I might as well just pull the plug now seeing as Windows 7 is reaching if not already in the fringes of compatibility with P3D and its add-ons. So I've spent a good portion of today reinstalling everything onto a clean install of Windows 10 and I'm happy to report that it seems to have fixed the problem.
No api.dll crashes; yet anyway, but time will tell...
-
I had a somewhat productive TM session with Umberto this morning - "somewhat" in the sense that he believed he had diagnosed the problem but wasn't able to fix it. Anyway, he suspected it was due to running Windows 7. While I was anticipating an eventual upgrade to Windows 10, I decided I might as well just pull the plug now seeing as Windows 7 is reaching if not already in the fringes of compatibility with P3D and its add-ons. So I've spent a good portion of today reinstalling everything onto a clean install of Windows 10 and I'm happy to report that it seems to have fixed the problem.
No api.dll crashes; yet anyway, but time will tell...
Well, that’s disappointing but I had a feeling that was coming! Naturally I’m happy for you, but if that’s what it takes to resolve this issue then count me out. Windows 10 is a definite no no as far as I am concerned and will remain so for the foreseeable future. Windows 7 has a lot of life in her yet. Arguably the best O/S produced to date by MS IMHO: fast, flexible, user friendly, very stable and with very few vices.
Also, I believe the Vulkan 3D Graphics API is now in direct competition with DirectX 12 and there is very encouraging evidence that an ever increasing number of Games Developers are adopting it to avoid forcing users to upgrade to Windows 10. Unlike DirectX 12 Vulkan has cross platform compatibility.
Anything that keeps MS’s intrusive and meddling ways at a distance is fine by me! If common sense was a factor then instead they should be exploiting Windows 7’s persistent success by giving serious consideration to allowing the continuance of this operating system (with limited support) alongside Windows 10 which, after all, is based largely on the former.
Have you seen Rob Ainscough’s recent demo video of Aerofly FS2 running under Vulkan? Truly astonishing! MS have had it their own way for far too long and I wouldn’t mind betting this potential ‘threat’ is the subject of intense discussions at Microsoft Redmond Campus. Perhaps they will be persuaded to extend support for Windows 7 beyond January, 2020 and reconsider their decision to deny Windows 7 users access to DirectX 12. Both scenarios seem unlikely but one can but hope. As with everything MS the ‘bean counters’ always seem to prevail. Witness what happened to ACES. Doubtless the staff were told that it was nothing personal, only business!
In the meantime, if I am told that I need to upgrade to Windows 10 to resolve this api.dll crash then I will live with it or simply disable the FSDT Addon Manager when I do not require GSX to be running.
I wonder if Vulkan is being considered by LM for Version 5? It could turn out to be a very wise move as it does seem to be an extraordinarily efficient API offering the same feature set and performance advantages as DirectX 12, making it an obvious choice for a developer looking to support as many users as possible.
Regards,
Mike
-
In the meantine, if I am told that I need to upgrade to Windows 10 to resolve this api.dll crash then I will live with it or simply disable the FSDT Addon Manager when I do not require GSX to be running.
Nobody has told you that, of course.
I'm trying to recognize a common denominator between you two and, there's a 3rd user who posted on Avsim that also has the API.DLL crash on exit and, guess what, he also use Windows 7 so, while I'm not by any means *sure* this is the real reason, it seems we are gathering some evidence it might.
Although it might be annoying to look at, since the crash is on Exit, and the sim IS closing down correctly (not stuck running), it's basically harmless, because Windows DOES have an automatic clean up of any resources used by application when they close, provided they do close, which is the case.
So, there's no need to disable GSX, because the only thing you'll eventually gain, is stopping to see the error in the Event Viewer, but the simulator performances won't change a bit.
I know exactly WHAT is causing the crash (the one I CANNOT replicate, mind...) on your systems, and it's a perfectly legitimate and 100% compliant call to the simulator PDK, required to do Render To Texture (RTT) with DirectX 11, which is almost identical to the sample provided by LM in the SDK, and is only doing a basic preparation work, for something we'll use in FUTURE products, namely KORD V2 and GSX Level 2. But, right now, we are not doing anything with it, just setup the system to be eventually used.
KORD V2 will use such features to display live information panels on the outside of the buildings, and live AI arrival/departure board inside the terminal.
GSX Level 2 will use it to create Jetways with their own individual number, saving A LOT of memory by not modeling each object separately (one for each gate), and allowing users to customize the font, color, style, etc.
But right now, none of this features are "live", only the preparation part is there, without doing anything.
Of course, as usual, we are always the first using cutting edge features but, I suspect that, when more developers would start using these features, you will have similar issues with those products too and, if the issue is really Windows 7, I'm not entirely sure if it would be possible to fix it or troubleshooting it. I assure you that almost every P3D4 developer, including LM, only use Windows 10. You must be crazy, as a developer, not using it, because that's the CURRENT version of Windows, and Windows 7 is not even the previous one, is TWO versions earlier, and as you pointed it out, is already started to be left behind by Microsoft.
I'll remind you that, "Mainstream" support for Windows 7 already ended in September 2015, and the "Extended" support will end in January 2020, so you can expect we'll stop restraining from using Windows 10-specify features, something we are still doing right now.
What we can do, right now, is as follows:
- Enable a user-configuration option (probably in an .INI file), to DISABLE support for the new PDK RTT functions. They are not really required now, so they will surely fix your API.DLL crash on Exit.
If you'll use this option, you won't be able to enjoy the information panels in KORD V2 (they'll appear black), and you won't see the jetway numbers with GSX Level 2, so you'll be in a similar situation of FSX users, since GSX Level 2 on FSX will not show Jetway numbers (there's no RTT in FSX).
But of course, you can always decide you don't mind the API.DLL crash on Exit, and disable that option, so you'll be able to use KORD V2 and GSX Level 2 in full.
-
There's an updated Addon Manager .DLL online now, which has an added option:
Disable RTT
In the Addon Manager settings, set the checkbox to disable the Render To Texture function, which should solve the API.DLL crash on Exit.
At this time, the Render To Texture function is not used by any of our addons so, until GSX Level 2 or KORD V2 will be out, it won't make any difference. After these addons will be released, you might want to consider re-enabling it, otherwise you won't have the airport live information panels or the jetway numbers in GSX (and KORD V2 too).
Assuming the problem only affects Windows 7 users, perhaps by the time we'll release KORD V2 and/or GSX Level 2, you might have upgraded to Windows 10. Or, you can just decide to live with the API.DLL crash on Exit (which is not really harmful) to have such features, or you can decide to just keep using GSX without such features. The choice is yours.
-
Hi Umberto,
Thank you, thank you!! You have cracked it!
https://i.imgur.com/y3QfYHm.jpg (https://i.imgur.com/y3QfYHm.jpg)
I had to perform a warm reboot of my PC before it worked, but since then ALL 3 EXIT ROUTES are now completing without any errors. Tested each route 4 times without any failures:
https://i.imgur.com/9gOfrVB.jpg (https://i.imgur.com/9gOfrVB.jpg)
Looks like that TeamViewer session won't be needed after all!
Well, it's been quite a journey, but the outcome is more than appreciated. Especially so since you did not turn your back on the problem and kept faith with those few who were affected by it. Now, that's what I call excellent Customer Support.
Also, many thanks for the detailed and interesting explanation about the likely underlying cause.
Best regards,
Mike :)
-
Looks like that TeamViewer session won't be needed after all!
Well, it was...after the one I had with Sabretooth78, where I could replicate the problem even with everything else disabled, so I started to suspect the problem could be specific to Windows 7 and, right now, everybody that reported the problem to still be there, are all using Windows 7, which explains why I couldn't replicate it and there weren't many users reporting it.
Not sure if it might be possible to have RTT working in Windows 7, it would require me finding a way to install Windows 7, perhaps on a Virtual machine, and debugging it in a way that might not be practical for users in a remote session and might take a long time, with the risk we'll found it cannot be fixed in any way, possibly because some differences in DirectX between Windows 7 and Windows 10 ( they are not exactly the same ) or issues with the sim itself under Windows 7, which couldn't be fixed on our side. That's the price you pay for being the first using the latest feature of the sim...
-
This helped. I was getting CTD when flying the AS CRJ-900 and mid flight P3D v4.3 crashed. Thanks.
-
This helped. I was getting CTD when flying the AS CRJ-900 and mid flight P3D v4.3 crashed. Thanks.
After the last post of this thread, GSX was updated to be disabled when flying over 10k feet so, if you got a crash over that altitude, it wasn't GSX and it wasn't the RTT function.
-
Just wanted to add a quick note to this topic. I am using windows 10 with P3D v4.4 and I have encountered the same exact problems with the video driver hung error. I currently own KORD, KDFW, KJFK, KLAX. The problem ONLY happens with KJFK and KLAX using GSX immediately after takeoff. If I don’t use GSX I did not have the error. Today I took off out of KLAX and used GSX after I disabled RTT in the addon manager and everything worked like a charm. Thank you for the “fix”!
Jeremy
-
Today I took off out of KLAX and used GSX after I disabled RTT in the addon manager and everything worked like a charm. Thank you for the “fix”!
Your problem is still there. That option is there as an emergency, because the very fact you have the "video driver hung error", indicates there IS some problem with your video driver, and GSX is only making it obvious, since it's one of the very few (if any) addons that use the new P3D4 SDK features called "Render to Texture", which allows to use ultra-fast DirectX code to draw text, lines, polygons, etc. Right now, we use it for all jetway numbers and the jetway battery charger indicator.
Of course, we only use 100% fully documented methods in the new SDK so, you can be sure this method is ultra safe, and if it wasn't, we would have hundreds of similar reports of something so obvious like a crash soon after take of in one of the two most popular FSDT sceneries.
So, the problem wasn't caused by GSX, but it appeared only with GSX, because no other addon is trying to use that 100% safe and documented API that, of course, requires your video drivers are in perfect shape, fully updated and with no undocumented tweaks. But yes, since we know that some users might have problems with video drivers, the "Disable RTT" option is there, so you can keep using GSX, until you'll eventually find your video drivers problem or reinstall the system or the sim, and it will likely go away.