Jump to content
Sign in to follow this  
Flyinggok

P3D - crashing after 4-5 hours with PMDG

Recommended Posts

Kernelbase.dll errors are very hard to isolate because the kernel is the center of the operating system which interacts with just about everything at a low level.  The previous posts are discussing video drivers, not sure if you have read the entire thread or just jumped in at the end.  Regardless, start looking at things like video driver..., I don't have Vpilot and I don't even know what it is but when isolating problems it is always a good idea to reduce the number of addons to see if the problem goes away... you don't even have to ask it should simply be one of the first things you try.


Dan Downs KCRP

Share this post


Link to post

Thanks for everyone's input. This is not the same issue as the "VAS leak caused by NVIDIA drivers", as far as I'm concerned. When I first installed the PMDG747, I was getting a major VAS leak but that problem was easily solved by downgrading to older Nvidia drivers. I'm still on the outdated drivers. 

 

This is a separate issue, it's an issue that's been going on for months/years. It seems very hard to pinpoint as some people get it but many people don't get it. There are posts both here and on the P3D forums about it. It seems that the sim crashes after 4-5 hours of flight, only when using a PMDG airplane. I still have a ton of VAS left, it's not a VAS problem, and sadly it almost always points to kernellbase.dll so it's hard to debug. 

 

For now my "workaround" has been simply to use time compression. I personally am not a fan of time compression, I've always liked doing it realtime, but it really appears the sim crashes after 4-5 hours of *real time* so using time compression (then auto-pausing if needed) prevents the crash. 

 

Its a odd situation, I'm sure one day someone will figure it out but man, this is weird!! Thanks for your help everyone. 

Share this post


Link to post
35 minutes ago, PhilH said:

It seems that the sim crashes after 4-5 hours of flight, only when using a PMDG airplane.

Are you using the left outboard CRT (pilot PFD) 2D popup?  If so..., don't instead use the right PFD for your 2D popups.


Dan Downs KCRP

Share this post


Link to post

I am indeed using the shift-8/9 commands when in external views, occasionally. Perhaps this is the culprit after all, I assume those shortcuts call the pilot PFD screens. I'll try without! Thanks for the idea.

Share this post


Link to post

Hi

I had similar CTDs with my PMDG planes (737, 777) in P3D on long flights (+4h). After reading alot here and in the P3D-forums I installed the P3D-SDK for the P3D version I use and I stopped using all of the popup windows of the planes (no PFD, ND, CDU...). Since then the only CTDs I had was/is an OOM from time to time. I do not know if one of the two or the combination worked for me, but it worked.

Greetings

Enrico Reiser

Share this post


Link to post

Phil,

Having read through this whole thread, you seem to be the only person in this thread having the CTD I am about to discuss.  Others are mostly jumping in with OOM/Overheat/Underpower/Hardware/Nvidia driver issues- and I want to specifically discount them from what I'm about to discuss.

When Lockheed Martin updated Prepar3D to v3.3, they broke something.  They get upset when I describe it this way, and we have had some back room discussion with them about finger pointing and laying blame- but there really isn't any other way to describe what happened.  Magically with the release of P3D v3.3, some users began to experience a CTD 4-7hrs after they used the pop-up displays in our products.  If they rolled back to v3.2.x the problem went away.

It is important to note that our product was not updated and did not change between the release of P3D 3.2 and P3D 3.3.

Thus- SOMETHING INSIDE PREPAR3D CHANGED, CAUSING THIS CTD TO OCCUR.

This is not the same as saying "It is Lockheed Martin's fault!"  It could be that as they have continued to adapt and grow their platform, they eliminated some function or created some change that causes a method inside our products to create mayhem after extended use- and we simply need to update our products to eliminate the issue.

The problem is that Lockheed Martin has been unable to tell us what that problem might be, and we have been unable to capture the problem with sufficient certainty in the debugging environment to tell them what it is...

We have been begging/pleading/cajoling Lockheed Martin to work with us to resolve this issue for 14 months.  The problem is not sufficiently troublesome to them to become a major concern, and we are unable to capture error messages coming out of their product, so we are more-or-less helpless to figure out where the CTD originates.  Lockheed have offered to take highly modified versions of our product to work with in their debugging environment, but only if we can give them an instantly reproducible failure mode- which is impossible.  Further, the modifications needed in order to satisfy their requests are impossible to accomplish without massively altering our product to the point where the potential return isn't worth the risks involved.  (Yes- this is political...no I won't blame them for their request... they are a Big Company and we aren't.)

In my opinion, the bottom line here is that Lockheed Martin doesn't want to invest 4-7 development/debug hours to chasing a possible CTD, and we aren't able to debug their work for them- so we have a problem that is going to get solved by accident, eventually.

At the end of the day, Prepar3D is THEIR platform, and THEIR changes to that platform created this problem.  We have changed export tools, SDKs, coding/debugging tools at their suggestion and none of these changes have moved anyone any closer to resolving the issue.

Right now my main hope is that the problem goes away in the conversion to x64....

In the mean time, we are still engaged in an all-hands effort to capture meaningful data on this CTD using our internal testing rigs, our beta team and a large number of customer machines.  So much effort is going into this process that it is having a negative impact on our development timeline- but we think it is important to keep trying since it negatively impacts a large number of customers.

This is the entirety of what we know and what we can do untill/unless Lockheed Martin decides that supporting you and us is important to them.

Big Companies...  It takes a big rudder to steer a ship...

 

  • Upvote 3

Robert S. Randazzo coolcap.gif

PLEASE NOTE THAT PMDG HAS DEPARTED AVSIM

You can find us at:  http://forum.pmdg.com

Share this post


Link to post

Hi Robert,

 

Thank you very much for taking the time to explain. I wish I would have posted this earlier this morning, but happily, I think I've finally come to a conclusion, and it makes sense with what you said: It's to do with the pop-up panels. I had always ignored people telling me to "not use the panels", because I thought they meant the sim would crash as soon as I opened the panels... which it didn't. It always crashed at a random time while I was away from my PC. However I was using the pop-ups pretty much every flight, either to get a nice window view + PDF or to use the FMC. 

I retried my NZAA-KLAX flight with the new B747 (about 12hrs of flight) last night. I didn't touch any pop-up panel. I made it to the other side without a crash or a single hitch! Once again I had well over 1GB of VAS left. Everything went well. This is the first time I've managed to fly for more than 7 hours real-time (no time compression) without getting a crash in several MONTHS. I am very pleased. I had the same problem with the B777, which had frustrated me and eventually made me stop wanting to use it (haven't flown it in about 5 months). I was annoyed when I saw the B744 had the same problem. But now that I know what's causing it, I can work around it, which is great. I don't know if what you just posted had been made clear elswhere (maybe I missed it?) but it certainly helps clear everything up. I understand the issue with the Big Company.. I don't see what could be done either.

I was too lazy/didn't feel like testing one individual pop-up to see which one/ones are causing the issue; I just used none on my flight. It isn't too annoying of a workaround, as I have simserver and use an iPad as FMC anyway. 

 

Once again thank you very much for explaining all this! I hope PMDG & Lockheed come to some kind of agreement one day, or that the problem gets fixed by accident as you said.

 

Regards,

 

Share this post


Link to post

Interesting thread.

 

So to clarify, are we only talking about the kernelbase.dll faulting module or is the ntdll.dll still in the mix.


Jock McIntyre

Share this post


Link to post
9 minutes ago, Jockos said:

Interesting thread.

 

So to clarify, are we only talking about the kernelbase.dll faulting module or is the ntdll.dll still in the mix.

Those two dlls are core Windows system files and crashes in them usually indicate deeper system-level instability. I believe what Robert is talking about here is the MSVCR120.dll crash associated with using the 2D popups.


Ryan Maziarz
devteam.jpg

For fastest support, please submit a ticket at http://support.precisionmanuals.com

Share this post


Link to post

I am not sure to be honest. I've only done 1 successful long real-time flight (as mentioned above) so far without using pop-ups. My crash was almost always a kernelbase.dll crash. It was very rarely a ntdll.dll, and even more rarely a MSVCR120.dll crash. So to the person above asking (Jockos), even if it makes no sense, try using no pop-up panels at all and see what happens.

Share this post


Link to post

Men

Thanks for the clarification/s.

I was curious as PhilH had not mentioned that he had MSVCR120.dll crashes and I was trying to relate Robert's message to the two crashes that Phil had experienced, kernalbase and ntdll.dll's.

My interest is in ntdll.dll and have never experienced a MSVCR120.dll.  I do use pop-ups and have flown up to 8 hours with no issues.  Well, occasional ntdll's.

Is there a connection?  I suspect not but it is worth trying a long haul without pop-ups.

Glad you are having some success, Phil

Cheers


Jock McIntyre

Share this post


Link to post

No problem! 

I always disregarded the people talking about pop-up panels as I wasn't getting MSVCR120.dll crashes either.. but after attempting no panels, I completed my 12 hour flight with no issue, and that's quite rare. Maybe a coincidence, I'll have to try again (tomorrow night), but for now it's looking promising.

Share this post


Link to post
12 hours ago, rsrandazzo said:

When Lockheed Martin updated Prepar3D to v3.3, they broke something.  They get upset when I describe it this way, and we have had some back room discussion with them about finger pointing and laying blame- but there really isn't any other way to describe what happened.  Magically with the release of P3D v3.3, some users began to experience a CTD 4-7hrs after they used the pop-up displays in our products.  If they rolled back to v3.2.x the problem went away.

It is important to note that our product was not updated and did not change between the release of P3D 3.2 and P3D 3.3.

Thus- SOMETHING INSIDE PREPAR3D CHANGED, CAUSING THIS CTD TO OCCUR.

 

 

Thanks for info, but when i check at your product page it says:

Recommended
Simulator: P3D v3.3 and up NOT COMPATIBLE WITH PREPAR3D 2.x

Then i have a couple of question's.

It says P3D v3.3, can i use P3D v3.2.3.16769?

If i'm gonna switch back to a earlier version, can i do this only with legacy Client change (Install_Client_3.2.3.16769) or must it be from scratch?

 

Just to clarify. ;-)

 

Share this post


Link to post

Unbelievable that we still have to make stupid workarounds for our sim to work properly. We are in 2017! Yes, I know this is LM's fault.

Recently my PC broke down, and this time I will no longer reinstall FSX on a new system. And considering many developers have cancelled plans for XPlane, it's either going to be P3D or nothing at all. I currently have the budget to build a new 2000$ system and buy all P3D addons, but these things are holding me back from taking the plunge, it's starting to look like another 10 years where we have to spend 25% of our flightsimming time to resolving problems. It is not normal for games or simulators to crash all the time. I also play racing simulators and with add-ons running in the background writing telemetry. I have driven hundreds of hours on these racing simulators, and never ever have I experienced a CTD. My time in FSX however saw random errors of all types, such as API.dll, MSVCR120.dll, ntdll.dll, kernelbase.dll, and the list goes on. 95% of my flight where trouble free, but whenever I encountered a problem, it took hours and sometimes days to solve it. 

Often when people are reporting problems, one of the first reactions is "There must be something wrong with your system."  I always cringe when I see that. A well-developed application should be able to handle some system instability, and not crash because of every single tiny thing.

Share this post


Link to post
15 hours ago, Jockos said:

My interest is in ntdll.dll and have never experienced a MSVCR120.dll.  I do use pop-ups and have flown up to 8 hours with no issues.

Same here!

I'm trying to track this issue down for a while now and recently changed my complete hardware:

My first 2 longhaul flights with my new PC  worked like a charm. ( YSSY - KSFO & YSSY - KLAX +14h flightime each ) and i used the CPTs PFD a lot. 

Meanwhile i'm on my 7th  westbound flight KLAX-YSSY in a row. Every of this flights crashed (ntdll.dll) after 9-10 hours while i was sleeping. (westbound 0/6 OK)

The only main difference between the succesful flights and the ones which failed, was the installation of FSDT GSX.

And that's why i deinstalled this software  also the FSDT plugins (Couatl and Addon-manager) before starting flight AAL73 the 7th time on which i am for 2:45h.  If GSX isn't

interfering my longhauls and my next eastbound longhaul flights work as they should the issue could be direction based. I also crashed the new A320 on a 5h leg westbound shortly before TOC with ntdll.dll when opening asnext destination METAR, something i never had before.

 

Share this post


Link to post

Create an account or sign in to comment

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

Create an account

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

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...