P3D v.3.3.5 constantly crashing/black out

[pytteros 4]

This June I bought new PC parts and built a new PC. I installed P3D v.3.3 and after few days I installed the just-released hotfix 3.3.5. During this month I have flown five flights, but I have landed the plane zero times -- I have never been able to fly to the destination due to this behavior:

 

1) Everything is fine, cruising at FL370 in 2D cockpit

2) I switch to VC, whole screen is black.

3) I change to spot view, it's also black.

4) P3D continues to fly and work, as I can hear the engines, and I'm able to disconnect the autopilot and trim the aircraft. (I can hear ap and trim sounds.)

5) Back to 2D, which has also became black.

6) Everything is black in P3D, windows and other programs are working normally

7) Sim runs for a while, then freezes and I have to hard reset my PC

 

My specs:

Intel i7 6700k - Default 4.0 GHz

ASUS Pro Gaming Z170

Asus Strix GTX980

16 Gb DDR4 RAM

Intel SSD 520 120 Gb with Windows 10 Home Edition 64bit

Samsung SSD EVO 850 250 Gb with P3D v.3.3.5

Western Digital HDD 1 Tb - Steam and other programs

EVGA G2 750W PSU

Dell U3415W 3440x1440

 

 

EGSS-ESGG
Addons in use: PMDG NGX, UK2000 EGSS, RCFlight ESGG, MT6, FTX Global Base, Ultimate Terrain Europe 2.0, FreeMesh X Global, GSX, FSUIPC
Flying on: Offline

CFG: AffinityMask=15, UseGlobalTerrainView=True, AlwaysFullLoad=1, FFTF=0.01

VAS remaining at crash: Unknown

 

Black out occured for the first time when I was established on the localizer at ESGG rwy 21. Everything went black the same way as described way above. No error messages and no data in AppCrashView or Event Viewer.

I thought this was just bad luck.

 

EGSS-LHBP, take 1

Addons in use: PMDG NGX, UK2000 EGSS, LHSim LHBP, MT6, FTX Global Base, Ultimate Terrain Europe 2.0, FreeMesh X Global, GSX, FSUIPC, ASN

Flying on= Offline

CFG: AffinityMask=15, UseGlobalTerrainView=True, AlwaysFullLoad=1, FFTF=0.01

VAS remaining at crash: Unknown

 

Black out occured over Belqium after passing the Canal. This time I got a weird fisheye-effect for few seconds in spot view with dissapeared aicraft before the black out happened again. I suspected this might be a VAS and OOM problem, since I'm currently on 3440x1440 resolution after years flying with 1920x1080. This is the first time I started to monitor VAS with ProcessExplorer and FSUIPC.

 

Just for remark: I have never experienced OOM on FSX with Windows 7 64bit. On FSX I had loads of sceneries and addons activated in scenery library, and I was still able to fly on 4096x4096 texture resolution and sliders to the right, flights like ESSA-ESMS-ESSA-LFPG-ESSA-LGAV with NGX on one go without restarting FSX and without disabling anything in scenery library. With P3D now,  my sliders are centered, LOD_Radius is 4.5 and texture resolution is 1024x1024.

 

At this point I updated my GPU drivers.

 

EGSS-LHBP, take 2

Addons in use: PMDG NGX, UK2000 EGSS, LHSim LHBP, FTX Global Base, Ultimate Terrain Europe 2.0, FreeMesh X Global, GSX, FSUIPC, ASN

Flying on= VATSIM

CFG: AffinityMask=15, UseGlobalTerrainView=True, AlwaysFullLoad=1, FFTF=0.01

VAS remaining at crash: ~1,1 Gb

 

I got a windows warning: "Close programs to prevent data loss. Your computer is low on memory" or something close to that. I decided to ignore that, and after ten secods, black out occured shortly after passing EDDF.

I also got a Prepar3d.exe error: "The instruction at 0x00000000675C4C60 referenced memory at 0X0000000000000014. The memory could not be read." Still, only Vpilot.exe crash was visible in AppCrashView and I didn't find anything remarkable in the Event Viewer linked to this.

 

I studied the CTD guide guide here on Avsim and I decided to raise the size of the paging file. It was system managed to this point.

 

EGSS-LHBP, take 3

Addons in use: PMDG NGX, UK2000 EGSS, LHSim LHBP, FTX Global Base, Ultimate Terrain Europe 2.0, FreeMesh X Global, GSX, FSUIPC, ASN

Flying on= VATSIM

CFG: AffinityMask=15, UseGlobalTerrainView=True, AlwaysFullLoad=1, FFTF=0.01

VAS remaining at crash: ~0,9 Gb

 

Black out occured near Hungarian border, shortly before Top Of Descend. No memory errors or pop ups this time, just the black out.

 

I decided to rebuild the shared cache, fly with minimized addons and a clean .cfg:

 

EGSS-LHBP, take 4

Addons in use: PMDG NGX, FTX Global, Ultimate Terrain Europe 2.0, FSUIPC, ASN

Flying on: offline

CFG: clean

VAS remaining at crash: ~0,7 Gb

 

I was on downwind for 31L in LHBP, when I got the same "Close program to prevent data loss..."-error. Everything got black, again. I decided to comply and closed P3D. No freezing or PC reboot was required.

 

---

 

So far, what I have done and seen:

- Not a VAS problem

- Updated graphics drivers

- Larger pagefile.sys -> not the solution -> back to system managed (virtual memory, not VAS-thing)

- "Zero tweaked .cfg"-test flight

- "only necessary addons"-test flight

- Rebuilt shader cache

- sfc /scannow - all was ok

- RAM diagnostics - all was ok

- Drivers are up to date

- P3D run as administrator

- Latest FSDT Addon Manager

- Nothing is overclocked

- DirectX diagnostics - all good

- UAC disabled

- Daily CCleaner

- Disable unneeded addon sceneries

 

I know P3D isn't supported on W10, but I've seen that many people can do it.

Help is needed, before I devide to format and install Windows again.

[DaveCT2003 1,820]

Can you try flying between two different airports that are no where near the airports and flight path you had the problems at, and see if you get the same error?

[pytteros 4]

Can you try flying between two different airports that are no where near the airports and flight path you had the problems at, and see if you get the same error?

I'll do that as soon as I can and report my findings.

 

I'm quite confused with this black out-phenomenon, as It seems to be more like a Windows or system related problem, rather than P3D-application related. This problem isn't normal application crash with error messages and faulting module names.

[Jim Young 2,356]

I'll do that as soon as I can and report my findings.

 

I'm quite confused with this black out-phenomenon, as It seems to be more like a Windows or system related problem, rather than P3D-application related. This problem isn't normal application crash with error messages and faulting module names.

I think it is your AffinityMask tweak setting.  However, you need to help us here.  Is there a problem posting AppCrashView report or show us an Event of the crash (as there is one.  It may show unknown module but there is one).  The AVSIM CTD Guide shows you where to look in the Event Viewer (there is only one place to look for all Events that occurred).  I would love to see whether you have the SweetFX or ENB Series modules installed.  Those are the most common for "blackouts".  Of course, language

 

Your list of things you have done is admirable but you forgot a couple of mandatory things to do and that's to move your p3d.cfg, dll.xml and your exe.xml and your scenery.cfg to a temporary folder and restart P3D and try the flight again.  You then bring them back one at a time until the crashes or freezes reoccur.  Your flightplans are quite resource intensive and couple that with ASN, FTX Global, the PMDG NGX, and UTX Europe is asking for trouble. 

 

So, IMHO, your "investigations" were all done wrong and were time-consuming.  Just moving the files as above and you could have figured it out relatively soon.  For instance, I am experiencing a StackHash, the most evil crash that anyone can get as there is no known fix.  I moved my dll.xml and exe.xml to a temp folder and the StackHash went away.  Problem solved except I now have to figure out what module caused it.  I think I already know it is... Orbx Objectflow_p3d or the SODE entries.  Easy to disable just those modules to find out but it is one of the modules.

 

You should never monitor VAS with Process Monitor.  Just use the freeware version of FSUIPC.  You should also make sure the FSUIPC is logging your VAS usage and provides a report.  The FSUIPC report can provide some valuable information.  It will tell you the amount of VAS used, the high, the low because VAS can be taken up instantly and then freed up and sometimes the VAS usage will go really low and actually provide more space during a long flight.  It's that coming in for a landing that is the killer in P3D (and FSX). 

 

Hope this helps.

[pytteros 4]

Thanks for your fast feedback.

 

Here is the latest blackout's log in Event Viewer. AppCrashView shows nothing related to P3D. Unfortunently, log is in Finnish, but I hope the important stuff shines through the language barrier. (Note to self, upgrade OS to English in future, everything will be easier for everyone.) I'm actually little ashamed to post this Finnish log to English forum, but that's all I can do. Fast translation provided in the log.

Seems like log is all about virtual memory.

 

Lokinimi:      System
Lähde:         Microsoft-Windows-Resource-Exhaustion-Detector
Päivä:         21.6.2016 22.12.45
Tapahtumatunnus:Event ID: 2004
Tehtäväluokka: Resurssien riittävyyden diagnostiikkatapahtumat Resource adequacy diagnostics events
Taso:          Varoitus Warning
Avainsanat:    Järjestelmän varausrajan (näennäismuistin) loppumiseen liittyvät tapahtumat. Events related to system's virtual memory limits
Käyttäjä:      SYSTEM
Tietokone:     DESKTOP-VCIRQSG
Kuvaus:
Windows määritti näennäismuistin vähyyden. Seuraavat ohjelmat käyttivät eniten näennäismuistia: Prepar3D.exe (4008) käytti 2182598656 tavua, firefox.exe (6568) käytti 371228672 tavua ja ASNext.exe (3644) käytti 277516288 tavua.

Windows determined low virtual memory. Following programs use virtual memory the most: ^^
Tapahtuman Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Resource-Exhaustion-Detector" Guid="{9988748E-C2E8-4054-85F6-0C3E1CAD2470}" />
    <EventID>2004</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>3</Task>
    <Opcode>33</Opcode>
    <Keywords>0x8000000020000000</Keywords>
    <TimeCreated SystemTime="2016-06-21T19:12:45.850001300Z" />
    <EventRecordID>4435</EventRecordID>
    <Correlation ActivityID="{1D8FC4B9-C869-409E-9FD3-166333562D79}" />
    <Execution ProcessID="964" ThreadID="3360" />
    <Channel>System</Channel>
    <Computer>DESKTOP-VCIRQSG</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <UserData>
    <MemoryExhaustionInfo xmlns="http://www.microsoft.com/Windows/Resource/Exhaustion/Detector/Events">
      <SystemInfo>
        <SystemCommitLimit>23244660736</SystemCommitLimit>
        <SystemCommitCharge>23123656704</SystemCommitCharge>
        <ProcessCommitCharge>4154388480</ProcessCommitCharge>
        <PagedPoolUsage>431759360</PagedPoolUsage>
        <PhysicalMemorySize>17093713920</PhysicalMemorySize>
        <PhysicalMemoryUsage>5648642048</PhysicalMemoryUsage>
        <NonPagedPoolUsage>271478784</NonPagedPoolUsage>
        <Processes>74</Processes>
      </SystemInfo>
      <ProcessInfo>
        <Process_1>
          <Name>Prepar3D.exe</Name>
          <ID>4008</ID>
          <CreationTime>2016-06-21T17:17:26.430960900Z</CreationTime>
          <CommitCharge>2182598656</CommitCharge>
          <HandleCount>3483</HandleCount>
          <Version>3.3.5.17625</Version>
          <TypeInfo>201</TypeInfo>
        </Process_1>
        <Process_2>
          <Name>firefox.exe</Name>
          <ID>6568</ID>
          <CreationTime>2016-06-21T17:27:45.836041900Z</CreationTime>
          <CommitCharge>371228672</CommitCharge>
          <HandleCount>991</HandleCount>
          <Version>47.0.0.5999</Version>
          <TypeInfo>210</TypeInfo>
        </Process_2>
        <Process_3>
          <Name>ASNext.exe</Name>
          <ID>3644</ID>
          <CreationTime>2016-06-21T17:25:26.192885200Z</CreationTime>
          <CommitCharge>277516288</CommitCharge>
          <HandleCount>549</HandleCount>
          <Version>1.0.6010.21922</Version>
          <TypeInfo>219</TypeInfo>
        </Process_3>
        <Process_4>
          <Name>
          </Name>
          <ID>0</ID>
          <CreationTime>1601-01-01T00:00:00.000000000Z</CreationTime>
          <CommitCharge>0</CommitCharge>
          <HandleCount>0</HandleCount>
          <Version>0.0.0.0</Version>
          <TypeInfo>0</TypeInfo>
        </Process_4>
        <Process_5>
          <Name>
          </Name>
          <ID>0</ID>
          <CreationTime>1601-01-01T00:00:00.000000000Z</CreationTime>
          <CommitCharge>0</CommitCharge>
          <HandleCount>0</HandleCount>
          <Version>0.0.0.0</Version>
          <TypeInfo>0</TypeInfo>
        </Process_5>
        <Process_6>
          <Name>
          </Name>
          <ID>0</ID>
          <CreationTime>1601-01-01T00:00:00.000000000Z</CreationTime>
          <CommitCharge>0</CommitCharge>
          <HandleCount>0</HandleCount>
          <Version>0.0.0.0</Version>
          <TypeInfo>0</TypeInfo>
        </Process_6>
      </ProcessInfo>
      <PagedPoolInfo>
        <Tag_1>
          <Name>MmSt</Name>
          <PoolUsed>98344720</PoolUsed>
        </Tag_1>
        <Tag_2>
          <Name>CM31</Name>
          <PoolUsed>98226176</PoolUsed>
        </Tag_2>
        <Tag_3>
          <Name>FMfn</Name>
          <PoolUsed>45908064</PoolUsed>
        </Tag_3>
      </PagedPoolInfo>
      <NonPagedPoolInfo>
        <Tag_1>
          <Name>smNp</Name>
          <PoolUsed>91222016</PoolUsed>
        </Tag_1>
        <Tag_2>
          <Name>ismc</Name>
          <PoolUsed>35635200</PoolUsed>
        </Tag_2>
        <Tag_3>
          <Name>smBt</Name>
          <PoolUsed>29245440</PoolUsed>
        </Tag_3>
      </NonPagedPoolInfo>
      <ExhaustionEventInfo>
        <Time>2016-06-21T19:12:35.363920500Z</Time>
      </ExhaustionEventInfo>
    </MemoryExhaustionInfo>
  </UserData>
</Event>

 

 

 

I would love to see whether you have the SweetFX or ENB Series modules installed. Those are the most common for "blackouts". Of course, language

Your list of things you have done is admirable but you forgot a couple of mandatory things to do and that's to move your p3d.cfg, dll.xml and your exe.xml and your scenery.cfg to a temporary folder and restart P3D and try the flight again. You then bring them back one at a time until the crashes or freezes reoccur. Your flightplans are quite resource intensive and couple that with ASN, FTX Global, the PMDG NGX, and UTX Europe is asking for trouble.

 

No SweetFX's or ENB Series' are installed, I don't like those.

I bet small frustration is visible in my first post, I literally ran out of ideas.   I'll perform another test flight testing those "mandatory things" and report my findings to this thread, if I find the potential culprit.

 

I agree my FSX-date fligthplans were quite suicidal, at least for a 32bit program like FSX, but I just flew in the limits of my PC and sim. I'm still wondering how I could fly 6-7 legs around Europe on FSX without restarting between legs, using heavy addons and sceneries, sliders to the right, and yet without any OOM's ever...

And what comes to the FSUIPC VAS logs, till now, I've only used the remaining VAS indicator in the upper left corner in P3D. I will also activate the log-file logging from now on.

 

Job first, then back to P3D. I'll report soon!

[Jim Young 2,356]

 

 

Lokinimi: System
Lähde: Microsoft-Windows-Resource-Exhaustion-Detector
Päivä: 21.6.2016 22.12.45
Tapahtumatunnus:Event ID: 2004
Tehtäväluokka: Resurssien riittävyyden diagnostiikkatapahtumat Resource adequacy diagnostics events
Taso: Varoitus Warning
Avainsanat: Järjestelmän varausrajan (näennäismuistin) loppumiseen liittyvät tapahtumat. Events related to system's virtual memory limits
Käyttäjä: SYSTEM
Tietokone: DESKTOP-VCIRQSG
Kuvaus:
Windows määritti näennäismuistin vähyyden. Seuraavat ohjelmat käyttivät eniten näennäismuistia: Prepar3D.exe (4008) käytti 2182598656 tavua, firefox.exe (6568) käytti 371228672 tavua ja ASNext.exe (3644) käytti 277516288 tavua.

Windows determined low virtual memory. Following programs use virtual memory the most: ^^
Tapahtuman Xml:

 

I did another translation of the above Event:

 

Task Category : Resource adequacy of diagnostic events Resource Adequacy diagnostics events
Level : Warning Warning
Keywords : relating to cessation of the booking system level ( virtual ) events . Events related to the system 's virtual memory limits
User: SYSTEM
Computer: DESKTOP - VCIRQSG
Description:
Windows determines that a shortage of virtual memory . The following programs were using the most virtual memory : Prepar3D.exe ( 4008 ) used the 2,182,598,656 bytes , firefox.exe ( 6568 ) used 371 228 672 bytes, and ASNext.exe ( 3644 ) used 277 516 288 bytes.
Windows Determined low virtual memory . Following programs use virtual memory the most :

 

I honestly have not seen this type of Event.  Maybe a new thingy for Windows 10?  Is there a reason why Firefox was running during your flight?

 

P3D and FSX were never developed to have the sliders moved all the way to the right or MAX.  Otherwise, no reason for sliders.  Just start it up and go fly.  No tweaking of the settings necessary.  I personally think it is impossible to run P3D/FSX with max sliders and the PMDG aircraft, ASN, and scenery like UK2000 (a massive resource killer) without running out of memory (which is what happened to you).  The enjoyment of FSX/P3D is not to see crisp/clear images on the ground while flying at FL320 or higher.  There is no people on the ground, no animals, and just fake cars, fake roads, and fake buildings to give you a sense of immersion and realism (but just a "sense").  When I come down to 3000 to 4000 feet, I like to see some sharp textures as I make my way toward the approach and landing but I am realistically busy in the cockpit preparing for the landing about that time (same after taking off).  So, you can get crisp clear textures with much, much lower settings and setting your limiter to 25 or 30.  I know because it works for me.  Having lower settings allows your CPU and GPU to render the textures faster.  Having max or very high settings and your system will be struggling.  So, you have found the far end to the right where you know crashes will occur for sure with sliders maxed.  Now I would set the settings to the default or the settings Lockheed picked based on your system specs (FSX and P3D read what you have installed and set the settings accordingly).  Of course the settings are not all perfect and you might have to adjust a couple of settings.  You also want to make sure you have the correct resolution (FSX was really bad at that). 

 

If Lockheed develops a 64 bit version of P3D, you will have something like 8 TB's of VAS so you might be able to max out your settings then but your CPU/GPU will still need to render.  But the good news is your chances of running out of memory will be reduced significantly.  What you need to do is go to the developers of your addon products and complain about all of the eye-candy they are putting into their products (so you will for sure buy their products). 

 

But I'm probably preaching to the choir as you appear to be computer literate.  I'm just reinforcing your thoughts that your flightplans ARE suicidal.

 

Best regards,

[pytteros 4]

I have found the problem!

I was inspecting VAS consumption with Process Explorer as I was flying from ESSA to LDSP. Blackout happened over Poland. I noticed in the Process Explorer that "commit charge" was at 99,97%. I closed all other programs quickly and blackout went away as Commit Charge dropped to 96.something %. I flew for a minute, black out came back and CTD happened. Free VAS vas >1,5 Gb.

https://en.wikipedia.org/wiki/Commit_charge

I started to wonder what caused the increase in Commit Charge. I flew same time with my friend, who uses FSX, and he reported that his Commit Charge rarely exceeded 40% on his machine.

I started a new flight, same fligthplan and everything. I kept my eye on Commit Charge all the time, and I found out that when I cycled view "S" through 2D cockpit, Commit Charge jumpted up a little. I continued to press "S": 2D -> Wingview -> Spot -> 2D -> Wingview -> Spot -> 2D.... and so on. After doing this for a minute, Commit Charge went to 100% and everything went black.

I tested this with Majestic Dash Q400 and default F22 Raptor. Majestic has a 2D panel and I was able to recreate the blackout with it. Default Raptor doesn't have a 2D panel, but I was able to recreate the blackout with it too.


All this makes sense now
- I love using NGX 2D panels. During my flight I change views multiple times between 2D, 3D and spot view. This slowly builds up Commit Charge and when it his 100%, blackout happens.
- All my blackout experiences have happened with NGX, because I use the 2D panels (In 2D view). With Majestic Q400, I never use the 2D panels, so I never cycle views through 2D cockpit. That's why blackout never occured with Q400, until I maliciously caused it with cycling views.
- Black out doesn't require plane to have physical 2D panels, only changing to 2D view causes jump in Commit Charge. That's why also Raptor can cause the blackout.
- I added CycleHidden=Yes to cameras.cfg cockpit-section and flew ESSA-LDSP again and guess what= Commit Charge never exceeded 50%, VAS remaining at Split was >1.0 Gb and I was able to fly from point A to point B!
- By disabling cockpit view, view cycling goes: 3D -> wingview -> Spot -> 3D and so on... This way Commit Charge does not build up, even when cycling with "S" for a minute.

It looks like there is problems with 2D view in terms of memory usage. Possibly just on my machine, or in P3D itself. I have had this same problem before and after fresh install of Windows.

Can some of you try to replicate this and report results? I can capture a video from this phenomenon to visually demonstrate what I've said in the text above.

[pytteros 4]

I would really like to hear if other fellow simmers here on AVSIM experience the same, what I described in the post #7 above. I have now flown multiple NGX legs without any problems. 2 months of investigating and head scratching has ended!

 

I also checked my event logs, and appcrash logs and found out that almost all CTD's with this case were kernelbase, .net framework or virtual memory related.

Now without using 2D viewpoint at all, zero crashes.

[Jim Young 2,356]

May explain why many get crashes and others, like me with the same scenario does not.  I never use 2D panels and always fly with the VC.  Glad you were able to find a solution.  I may try to get your "fix" in the next rendition of the CTD Guide with a link to this topic.  There are so many configurations it is difficult to pin down a solution that fits everyone.  Computers systems, games, and humans do not match.