PGBosak

3rd crash, same flight: now pointing to immersion manager: Name der fehlerhaften Anwendung: Prepar3D.exe, Version: 4.4.16.27077, Zeitstempel: 0x5bfdbb35 Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.16299.785, Zeitstempel: 0x11105c69 Ausnahmecode: 0xc0000374 Fehleroffset: 0x00000000000f849b ID des fehlerhaften Prozesses: 0x22f4 Startzeit der fehlerhaften Anwendung: 0x01d4a78a56a94253 Pfad der fehlerhaften Anwendung: E:\P3Dv4\Prepar3D.exe Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll Berichtskennung: b2fe4b5b-2c05-40a6-a992-c52a63e29272 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist: Application: Immersion Manager.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException at <Module>.SimConnect_WeatherRequestInterpolatedObservation(Void*, UInt32, Single, Single, Single) at LockheedMartin.Prepar3D.SimConnect.SimConnect.WeatherRequestInterpolatedObservation(System.Enum, Single, Single, Single) at A.m.C(Int32) at A.V.A(System.Object, System.Timers.ElapsedEventArgs) at System.Timers.Timer.MyTimerCallback(System.Object) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.TimerQueueTimer.CallCallback() at System.Threading.TimerQueueTimer.Fire() at System.Threading.TimerQueue.FireNextTimers() Name der fehlerhaften Anwendung: Immersion Manager.exe, Version: 1.0.18.0, Zeitstempel: 0x5c313cbe Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.16299.785, Zeitstempel: 0x11105c69 Ausnahmecode: 0xc0000005 Fehleroffset: 0x000000000004a6fb ID des fehlerhaften Prozesses: 0x211c Startzeit der fehlerhaften Anwendung: 0x01d4a78a61d9b4dd Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\OldProp Solutions Inc\Immersion Manager\Immersion Manager.exe Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll Berichtskennung: 8f90c6a2-7cd9-40d8-9f18-a1069f11b3f4 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

I use it (except the lights options) with 744 and 748. But i can't remember crashes with 744 it is just the 748 and i had one single crash some months ago with 748 related to MS Internet explorer. (Maybe an EFB issue, i don't use the MS browser normally)

Same issue here. I am currently on DLH721 and the 747-8i crashed the second time during the flight. ☹️ No problems with 744 and 777 (p3dv4.4) or my FSL A319/320 ZBAA KM31D KM A596 TZH B458 TMR G343 NIXAL Y683 NIGOR P983 ABESA L158 BENAK A487 BABUK B236 LUKAS L166 LUNAG A713 NOGRI T872 OK R834 MF MF7T LAPUR FE5T AR FE2T BG L29 SUW T727 DENKO N858 SUBIX Z20 LOGDO Z117 ORTAG T177 ODIPI T157 KERAX KER07S EDDF The latest crash was short of OSBAL @ airway A713 (ntdll.dll) my setup: | CPU: Intel i7 7700K @ 4,8 GHz | COOLING: Corsair H115i @ SP140 | MB: ASUS Z170 Del. | GPU: ASUS 1080GTX A8G | AUDIO: Creative SB Z/ Teufel Concept E 450 Digital Superior Edition | RAM: 16 GB DDR4 2666 | SSD:Samsung 850 PRO 256/512 GB | Headset: Beyerdynamic MMX 300 (2nd Gen.) | MONITOR/TV: ACER PREDATOR XB321HK/Panasonic TX-50DXW734 | OS: W10 PRO 64 bit Build: 1709 (16299.785) SIM: P3D v4.4.16.27077 | NV-DRIVER: 398.36 WHQL | FSUIPC: 5.1.5.0 | WX: AS16 + ASCA | ENVIRONMENT: Envtex 1.1.6 | Envshade 1.0.5 | Envdir: 1.1.2.5 | FTX Global Basic, FTX LC EU/NA/SA | FTX Vector | GSXv2 | VC VIEW:ChasePlane 1.0.24 | CONTROLS: Thrustmaster HOTAS Warthog | RUDDER: MFG Crosswind |

In general you are being right, but you forgot about the desktop heap limitatation issue: https://troubleshooter.xyz/wiki/how-to-fix-out-of-memory-error/ Often been an issue in W7 environment, in W10 natively set higher as far as i remember, but could also result in OOM. You can also experience an oom when no or a small pagefile is set and you minimise the sim.

...when "new window style" is chosen: https://ibb.co/ftop4U

For a moment I wondered if I could have mixed up ceilings or interpreted them wrong. Then i've read this paragraph: "The point where high-speed Mach, IAS, and low-speed buffet boundary IAS merge is the airplane's absolute or aerodynamic ceiling. Once an aircraft has reached its aerodynamic ceiling, which is higher than the altitude limit stipulated in the AFM, the aircraft can neither be made to go faster without activating the design stick puller at Mach limit nor can it be made to go slower without activating the stick shaker or pusher. This critical area of the aircraft's flight envelope is known as coffin corner." [FAA Handbook FAA-H-8083-3A, page 224] taken from: http://code7700.com/aero_coffin_corner.htm That precisely states coffin corner and also aerodynamic ceiling don't "drift down" to any aircraft altitude state within normal operating FL. It's a theoretical issue nowadays. There are tons of visual graphics and expertise on the internet which insist it does, starting with wikipedia. From my perspective they must be wrong if FAA is being right. This phenomenon appears not only above service ceiling but also beyond absolute ceiling. And the low climb rate which defines the service ceiling will prevent you to ever get near coffin corner in real.. I know we are off-topic but i find it interesting to debate, because there are a lot of reverse assumptions out there. You wouldn't have to define those ceilings if coffin corner may appear at any upper operational flight-level. Doesn't make really sense. 😉 Those certifications are here to avoid any risk in relation to this topic. cheers

Hi Emi, several years ago i borrowed a book about aviation and it stated that coffin corner is one of the parameters that sets the limit for service ceiling. About the correlation between stall speed and critical mach number in relation to coffin corner you can even read in Wikipedia. A real pilot answers the question: "What is coffin corner?" in that way: Answer: Coffin corner is a term used to describe a condition at high altitude when the maximum speed (limited by the spreading of supersonic shock waves) and the minimum (limited by amount of air passing over the wing) are nearly the same. This has caused cases where the airplane could not fly faster due to the high-speed limit or much slower due to the low-speed limit, making it difficult to control during turbulence or when descending. One extreme example of the coffin corner is the U-2 – the difference between the famed spy plane’s high-speed limit vs. low-speed limits is quite narrow at the extreme altitudes of 60,000 feet or more. It is a very challenging airplane to fly because of the small acceptable airspeed window. Most modern jetliners have good speed margins, making coffin corner problems an issue of the past. source: https://eu.usatoday.com/story/travel/columnist/cox/2015/07/24/coffin-corner-cruising-altitude/30615399/ as you are german, the german wikipedia-site also states: "Die Dienstgipfelhöhe liegt immer unterhalb des Coffin Corner, da sie dadurch definiert ist, dass noch eine Steigrate von 100 ft pro Minute beim Propeller-Flugzeug und 500 ft pro Minute beim Strahlflugzeug möglich sein muss. Dies wäre jedoch in der Nähe der Coffin Corner nicht mehr der Fall." another source: https://www.skybrary.aero/index.php/Coffin_Corner "In commercial and general aviation operations, flight at altitudes approaching coffin corner is generally avoided. Compliance with the aircraft manufacturer's maximum operating altitude in ISA conditions given in the AFM, if necessary taking account of the difference between actual conditions and those of the ISA, will normally ensure that adequate buffet margins are maintained for both the high and low speed boundaries." Are all of those sources wrong? 😉

From my understanding of aerodynamics you/your virtual airline have/has a wrong perception on the principle of coffin corner. This phenomenon you're taking into account appears beyond service-ceiling solely and this service-ceiling is being constant, based on test-flights with security margin. So your climb performance within your legitimate planning stepclimb-range has nothing to do with taking risk in relation to coffin corner, because if you really get near to that phenonemom you are already beyond service ceiling. That shouldn't ever happen. Coffin corner shows a situation where stall speed and critical Mach number gets equal. So you have to fly higher than FL451 with 744 or higher than FL431 with 7474-8 to experience the risk of coffin-corner.

If your FMA shows "FAC" you are on an IAN-approach (integrated approach navigation). So you have to land manually because this kind of landing mode is non precition. But with your information given, i can't tell you why exactly the flight mode has changed. But there is a feature to correct the LOC Course to the SIM: quote: "CORRECT LOC CRS TO P3D: When it comes to navigation data, P3D has an inherent weakness in that data related to ILS/LOC stations is hard coded into the simulator and is not updated to keep it current with the normal magnetic shift. The end result is that the localizer final approach course in the P3D world will sometimes vary from the real world. Since many users are also using real-world navigation charts, this can create some confusion and can also create problems if the LOC course is not correctly set to match the P3D hard-coded information. (The airplane cannot fly the localizer properly if the CRS on the CDU NAV RAD page is set incorrectly) To compensate for this, we recommend setting this option to ON, and we will read the appropriate P3D localizer course and adjust the setting for you, thus saving you time and frustration." (Page 98 PDF Introduction manual 744-748)

There is an option within GSX module to expand the actual wingspan of the current parking position to the maximal wingspan. If done every heavy gate should be fine.

Got 4 new activation keys with my 748 purchase, which one should i use?

Hi Dan, forgot to mention, i also tried to reset the INS alligment first. the input zero was being kept.

Hi guys, i know this data is provided by Navigraph randomly, but i always try if it's available. Because of different gate info between charts and addon-scenery (in that case ZBAA data). I checked different gate data format inputs to get knowledge if just my chosen gate wasn't stored in Navigraph database or they were generally missing. I found one working, which gave out gps position reading. After that i wanted to clean this info, but it wasn't possible to find a proper way. I also tried the digit "0" This replaced the input before, but was represented by a different gps position again. But i wanted to solve this but I didn't want to close the sim and start it again. So i decided to reload the cold & dark profile. And then something strange happened. The "wrong" input "0" in the field of gate-positions was still there and kept. And that's the reason why i write this post. Is this intentionally behaviour? As far as i remember PMDG did some "hardening" back in the MD-11 years to avoid wrong user-inputs which led to crashes sometimes. Please correct me if i understood the concrete logic on this topic wrong!: It needs a proper Navigraph database readout to replace a wrong gate number input. But we all know they aren't complete, which makes corrections difficult. And there is no other option to clean this field. You can't replace the wrong GPS data itself by input of the correct GPS-position taken from airport charts. (i checked this too) also a C&D panel state reload keeps wrong gate data. Maybe i missed something, but as user i would be happy to be able to clean this Gate-Numbers line as every other parameter in CDU in every aircraft withoud closing the whole sim.

For those who still have issues when loading the queen into P3Dv4.2 and are using chaseplane you can give this a try: Open chaseplane from desktop: Switch back from "experimental mode" to "normal mode" and untick in preference menu "start chaseplane with P3D" If the Queen loads successfully now close the sim open chaseplane again and change back to experimental mode and tick the autostartoption again. In my case eventmanager pointed with kernelbase error directly to chaseplane and that procedure fixed it. Hope it helps

Thank you so much, don't know why i didn't get it myself.

Hi guys, i'm new to chaseplane and i wonder if there is an option or trick to get the coolie-hat working in chaseplane view. It really annoys me. I just can use it, in native P3D views when when my controllers are active (checkbox) in the sim. But my controllers are linked to fsuipc and disabled in the sim. Before installing chaseplane i was able to use coolie even if my controllers are disabled in the sim. I don't want to buy trackIR soon and i'm used to move around from EZDOK. Mouse-mode isn't an adequate option. Thx for any help.

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.

glad you've fixed your issues, happy flying!

I had hoped this is at least solved in the actual release. Btw. is the Captain PFD popup crash issue solved meanwhile, as known from 77LR/F. The funny thing i don't have it with the 300ER.

Some on the pics @gonemissed had uploaded are showing that he uses EZDOK camera (upper right corner) The effect section of this tool (v2) is known to affect control of the aircraft. So i'd disable all those functions in no-weather-condition to see i the A/P issues are gone.

exactly!

No problem. Here is all the information to repeat this flight yourself : aircraft 77W fuel: 127.84 tons zfw 222.5 tons t/o weight 350.0 tons CI 85 (t/o 00:15z, weather 16.02.2017 ASN) intital Level FL200 after 8 h climb to 330 then SC as computed. YSSY N0491F290 KADOM1 KADOM A576 TESAT B450 NOBAR A579 VIRAR/N0501F310 A579 NN B581 WACOS/N0494F330 B581 CAMOS/N0488F350 B581 WEDES/N0480F370 B581 FICKY C1177 ROSIN BUFIE4 KLAX weather forecast uploaded for FL310 FL330 FL350 FL370. As customer my job ends with informing you. With or without finger smiley. :wink:

i think you didn't get my point, from the logical view. When the prediction says from the start following all the SC the aircraft will land with 12 Tons left and i actually land with 12 Tons knowing i flew 8 of 14 hours at FL200 we don't talk about prediction anymore, but actual consumption and that lead us back to my initial topic. here's a famous Abraham Lincoln quote that might fit here. this one? http://www.bilder-upload.eu/show.php?file=40b0e6-1487253416.jpg Btw i just saw the meaning (here) behind that smiley, thats not what i intended to say. Sorry! That Finger gesture has normally a different meaning. (in the offline world)

On my yesterdays overnight flight i forgot set altitude bug for initial climb level before going to sleep. So the aircraft leveled at FL200 for exact 8 hours. When i came back, i saw the aicraft still cruising at FL200 so i checked fuel prediction. It showed the same 12 tons at arriving in klax as calculated before t/o. I wouldn't say that's normal behaviour. :Shame On You:

Hi, I had some nasty stability issues in the last weeks, without touching anything during flight. That's the main reason i had crossed the pacific ocean more than a dozen times. Sometimes i just tried to. This issues seem to be solved meanwhile. Looks like they were net.-framework related. On my yesterdays leg i had enough time to waste some thoughts on the PFD crash issue. I knew it never happened on ground to me when departing and even not after landing. The trigger has to be something that happens enroute. I looked at the PFD, saw the past flighttime since departure (+10 hours inflight) Could it be time related i wondered? I was at FL360 (autostepping from initial level 300) inbound Norfolk VOR meanwhile, I looked into the upper right corner of the PFD. What if this trigger is flightlevel related? A good chance to test it, so I stepped down in 1000ft steps. FL350 popup CPT PFD nothing happened FL340 popup CPT PFD nothing happened FL330 popup CPT PFD nothing happened Unintentionally i let the PFD zoomed when i descended to FL320 (mouse was still "parked" over the PFD) When the digits reached exactly 32.000 the complete screen turned into white and the "blue ring of wait" appeared over the PFD. I thought the sim would quit in some seconds but it recovered. Maybe because the captains PFD was already zoomed before reaching FL320? That could be also the reason why some never had experienced it. If your initial climb level ist above this value because you are flying a shorter leg, you won't have any chance to popup PFD when in cruise at FL320. :wink: Maybe some of you would like to reproduce this. I'll definitely will do this flight again soon and check if this issue actually is really being flightlevel related. Maybe it's nothing but i think this should be ruled out. That event was so exactly at 32.000 that i don't believe in coincidence. my testbed: W7 SP1 64bit, P3Dv3 actual release netframework 4.6.2 (only) MS ESP Sim Connect v1.0.20.0 3 simconnect FSX clients VisualC ++ 2010 x86 10.0.40219 Visual C ++2013 x86/x64 12.0.30501 I5 2500k/ Z68 asus board/Nvidia 375.70 /ASUS 1080 GTX ASNext actual release (networked as ivap)