4 hours ago, mwa05 said:

I have been suffering from CTD’s and Freezes for about a month and I purchased and installed MSFS on a brand new, custom built computer in October 2022 and had never had a CTD.

I have been sick for a few days so have not been to work and today I decided to look into the issue.

Using event viewer, I was able to ascertain that it started on 20OCT23. Tracing back I was able to ascertain that the only change to my computer was a Nvidia driver update (545.84) which I installed on 18OCT23 via GeForce Experience (and I have always updated when a new driver was available, and for years), Current driver on system 546.17. 

I did a fair amount of googling which lead me to a Reddit Nvidia page, where it seemed from that chat from users that the last stable driver was 537.58 and this seemed to be almost universally agreed.

So I uninstalled GeForce Experience (logging out first as per Reddit) and using DDU, removed 546.17 and I then installed 537.58.which I had downloaded and had ready to go.

Result? No CTD’s and have flown two full, stutter free, error free flights tonight. So be weary of Nvidia drivers higher than 537.58.

It has been so uplifting I feel better and have reported fit to crewing.

You are describing the exact reason that I stopped updating Nvidia drivers years ago. If I have a driver that is working well,, I don't "fix it" by changing to a new one. The driver I am currently using was installed in my present PC, when I purchased it over 2 years  ( 472.88)  . I have had 1 CTD in two years. 

Edited November 24, 20232 yr by Bobsk8

6 hours ago, boez said:

You can find that out both in this thread and the one on the official forum

Last night I made several flights in the PMDG 737 with JF Traffic on and not one problem.  I see per this thread that there seems to be two different type of CTD inducing behaviors.  I’ve never had the “map” CTD.  Mine has always been exactly as Landon describes.  CTD precisely at spawning.  Having spent my real life working real aviation is one thing, but since I never learned networking I’m not familiar with this half-duplex and 100 Mbit business but I know it works.  It may not be perfect but it’s indicative of where SU13 went wrong regarding coding right?

This PC I use is only for MSFS, I don‘t even have email set up on it and use no other apps or games on it.  Anyway, all I can hope for now is MSobo will fix it if they’re even aware of it and if they even care.  

When I was having the CTD’s especially in flight, this has induced in me the same dreadful feeling of crashing to desktop as was felt in the days of OOM’s in FSX so it is no longer a relaxing hobby, it’s stress inducing as you never know when it might just quit.  This is not how I want to spend my time.

1 hour ago, Jack_Sawyer said:

I see per this thread that there seems to be two different type of CTD inducing behaviors.  I’ve never had the “map” CTD

The very specific issue which the network connection workaround helps with is whenever MSFS is loading terrain tiles from the server (and no other type of CTD such as 3rd party addons, drivers, etc.). That occurs in 5 places:

loading simulator 

world map 

loading flight (blue bar at around 80%)

flying, and, as added by another poster,

while looking for scenery in the marketplace.

edit: the most ‘stressful’ time, i.e. when the most terrain tiles per second are being loaded, is during map zooming and flight loading. This is the likely reason that most CTDs caused by this (apparent) speed issue occurs at those times. 

Background: So around mid October posters on the official forum thread were seeing CTDs in some or all of these places with no apparent common connection. Personally for me CTDs on the map were rare but loading flight was common. After I asked for hardware specs one common feature of all the posters were that they were on high speed network connections hence my workaround to slow it down. I must repeat that this was just a hunch on my part and asobo did not confirm the cause. However the workaround is still good a month later. It is also not the solution nor is it intended to be. That needs to be fixed by asobo and/or Microsoft (at the server). 

1 hour ago, Jack_Sawyer said:

It may not be perfect but it’s indicative of where SU13 went wrong regarding coding right?

I was on the su13 beta for 2 months and never saw the issue. A few days after the public release of su13 I, along with others, started seeing the CTDs. BUT no code changes were made to the beta version once it went public. So why didn’t I see the CTDs during the beta if it was in the code? Again my hunch is a configuration change on the server but I guess only Asobo will know for certain. 
 

edit: for perspective I had more CTDs in 3 days before the workaround than I’d had in 3 years of using the sim. I’m guessing with that uptick in frequency that I’d have seen a CTD during the 2 month beta if it were in the code. 

Edited November 24, 20232 yr by boez
Additional info

4 minutes ago, boez said:

The very specific issue which the network connection workaround helps with is whenever MSFS is loading terrain tiles from the server. That occurs in 5 places

loading simulator 

world map 

loading flight (blue bar at around 80%)

flying, and, as added by another poster,

while looking for scenery in the marketplace.

So around mid October posters on the official forum thread were seeing CTDs in some or all of these places with no apparent common connection. Personally for me CTDs on the map were rare but loading flight was common. After I asked for hardware specs one common feature of all the posters were that they were on high speed network connections hence my workaround to slow it down. I must repeat that this was just a hunch on my part and asobo did not confirm the cause. However the workaround is still good a month later. It is also not the solution nor is it intended to be. That needs to be fixed by asobo and/or Microsoft (at the server). 

I was on the su13 beta for 2 months and never saw the issue. A few days after the public release of su13 I, along with others, started seeing the CTDs. BUT no code changes were made to the beta version once it went public. So why didn’t I see the CTDs during the beta if it was in the code? Again my hunch is a configuration change on the server but I guess only Asobo will know for certain. 

Thank you for your excellent explanation, I appreciate it.  And you did a great job sussing this out, it’s been very helpful!

6 hours ago, Bobsk8 said:

You are describing the exact reason that I stopped updating Nvidia drivers years ago. If I have a driver that is working well,, I don't "fix it" by changing to a new one. The driver I am currently using was installed in my present PC, when I purchased it over 2 years  ( 472.88)  . I have had 1 CTD in two years. 

I update my NVIDIA drivers every time there are new ones out, no crashes here.

Edited November 24, 20232 yr by Tuskin38

29 minutes ago, Tuskin38 said:

I update my NVIDIA drivers every time there are new ones out, no crashes here.

Same here.

35 minutes ago, Alvega said:

Same here.

If I had a dollar for everytime I read someone updating their drivers, going back to the FS9 days, and had problems, I would own my own Kodiak...😉

i update  my  drivers  when ever  there is  a update  had  zero  issues

4 hours ago, Bobsk8 said:

If I had a dollar for everytime I read someone updating their drivers, going back to the FS9 days, and had problems, I would own my own Kodiak...😉

That was then, this is now

I managed to complete a night flight yesterday in the USA and benign weather, of about 2hr duration in the Vision jet (note not my normal BlackSquare B58), and no CTD .. hooray.

This gives me a small hope of trying another longer distance trip across Europe tomorrow. Flying for any length of time in IMC does appear to have an impact on CTD typical ofthe OOM we used to get in FSX.

At present I've uninstalled WU6, reduced my network speed to 500Mb + 1/2 duplex.

Reducing my network speed to 100Mb + 1/2 duplex has fixed the CTD issue for me. Hopefully this gets addressed in some future update.

I had ctd with every new Nvidia driver every time over and over again. I was using dx12, rtx 4090 and 7900x3d processor and also VR. MSFS was unstable as soon as I used a driver newer then 537.58

Now I updated to the latest beta since 3 days. Already had one beta update too. NOT a single ctd anymore. Zooming into the world map also is not causing issues anymore. 

I can play with my settings again while midflight (testing stability because prior the beta, with su13, my sim ctd all the time when switching between DLSS and taa mode). Now al stable again. Performance in my case stayed exact the same btw. 

I do hope you all will enjoy the new SU14, because the release notes say that several crashes among the title have been fixed. Of course there will be exceptions. 

But dx12, and driver hung issues seem "passed". 

Just my thoughts and sharing my personal experience. And I was very very reluctant updating to a beta version. I'm glad I did now. 

Edited December 3, 20232 yr by mpo910

On 11/21/2023 at 6:06 PM, craigeaglefire said:

 must admit that I’m very pleased with the Seasonic Platinum 1300W PSU with 3090 Strix OC (for those word not allowed micro power spikes that MSFS generates)… 🙂

 

(most people don’t seem to factor in that a PSU is most efficient in its 50% output power zone)

100% I have an EVGA 1600w PSU and no CTD problems. The most underappreciated component in computers these days, IMO.

On 11/22/2023 at 6:27 PM, sniper31 said:

In my case, NO, not during final approach. It happens to me right when I hit the Fly Now button, sometimes in mid-flight at cruise altitude, or after I have landed and have reached a parking spot (at either a busy or completely empty airport).

This is the exact same SU13 CTD error code I have been getting. 

Seems like you've played around with this long enough. Time to get serious and figure out what is really going on. I suggest enabling memory dumps in Windows and downloading WinDbg (which you can d/l from MS for free). Next time that you get a CTD, locate the dump file (use Explorer to search for *.dmp files with today's date). Run WinDbg as admin, and then select "Open crash dump...". Select the .dmp file corresponding to the time of the crash and let it load. In the window that displays, you'll see a line that reads, "For analysis of this file, run !analyze -v". The part that says "!analyze -v" will be highlighted in blue. Click it and it will run. Now you will see exactly what was going on when it crashed. Paste the results in this thread.

Below is the output of the analysis of the last actual crash on my computer from last January. I had a memory stick go bad. It was memory corruption, just like the analysis said.

Microsoft (R) Windows Debugger Version 10.0.22621.1778 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.

Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (20 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff800`12c00000 PsLoadedModuleList = 0xfffff800`1382a290
Debug session time: Sun Jan  8 13:22:20.488 2023 (UTC - 5:00)
System Uptime: 0 days 0:12:37.186
Loading Kernel Symbols
...............................................................
................................................................
................................................................
....
Loading User Symbols

Loading unloaded module list
........
For analysis of this file, run !analyze -v
1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000099, Attempt to free pool with invalid address  (or corruption in pool header)
Arg2: ffff980bc235aeb0, Address being freed
Arg3: 0000000000000000, 0
Arg4: 0000000000000000, 0

Debugging Details:
------------------

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 4796

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 8624

    Key  : Analysis.Init.CPU.mSec
    Value: 5406

    Key  : Analysis.Init.Elapsed.mSec
    Value: 22749

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 88

    Key  : WER.OS.Branch
    Value: vb_release

    Key  : WER.OS.Timestamp
    Value: 2019-12-06T14:06:00Z

    Key  : WER.OS.Version
    Value: 10.0.19041.1

FILE_IN_CAB:  MEMORY.DMP

BUGCHECK_CODE:  c2

BUGCHECK_P1: 99

BUGCHECK_P2: ffff980bc235aeb0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXWINLOGON: 1

PROCESS_NAME:  System

STACK_TEXT:  
fffffa0b`ebd17168 fffff800`135d1e34     : 00000000`000000c2 00000000`00000099 ffff980b`c235aeb0 00000000`00000000 : nt!KeBugCheckEx
fffffa0b`ebd17170 fffff800`1319f421     : ffff980b`c235aeb0 00000000`00000350 00000000`000000c2 00000000`00000000 : nt!VerifierBugCheckIfAppropriate+0xe0
fffffa0b`ebd171b0 fffff800`1302709c     : ffff980b`98e02000 00000000`00000705 ffff980b`c235aeb0 ffff980b`bfdf5598 : nt!VerifierFreeTrackedPool+0x41
fffffa0b`ebd171f0 fffff800`135b5019     : ffff980b`ba0cd690 fffff800`12e0e4be ffff980b`ba0cd040 01000000`00100000 : nt!ExFreeHeapPool+0x20314c
fffffa0b`ebd172d0 fffff800`16d13eab     : ffff8686`db388010 00000000`00000705 ffff8686`db3881a8 fffff800`1325d7ec : nt!ExFreePool+0x9
fffffa0b`ebd17300 fffff800`16d19910     : ffff980b`c235ba30 ffff980b`bfdf5538 00000000`00000001 00000000`00000000 : Ntfs!ExFreeToNPagedLookasideList+0x53
fffffa0b`ebd17330 fffff800`16e3260f     : fffffa0b`ebd17468 fffffa0b`ebd177f0 fffffa0b`ebd177f0 00000000`00000705 : Ntfs!FsLibUninitializeRangeLock+0x64
fffffa0b`ebd17360 fffff800`16e32366     : ffff8686`db388170 fffffa0b`ebd177f0 ffff980b`b82099f8 ffff8686`00008000 : Ntfs!NtfsDeleteScb+0x1af
fffffa0b`ebd17400 fffff800`16d197b5     : 00000000`00000001 ffff8686`db388170 ffff980b`c234ba50 00000000`00000000 : Ntfs!NtfsRemoveScb+0x66
fffffa0b`ebd17460 fffff800`16e320fc     : fffffa0b`ebd177f0 00000000`00000000 ffff8686`db388010 ffff980b`b8209100 : Ntfs!NtfsPrepareFcbForRemoval+0x75
fffffa0b`ebd174a0 fffff800`16d18f76     : fffffa0b`ebd177f0 ffff8686`db388170 ffff8686`db388468 ffff8686`db388010 : Ntfs!NtfsTeardownStructures+0x9c
fffffa0b`ebd17520 fffff800`16df4532     : fffffa0b`ebd177f0 fffff800`16e08fc0 00000000`00000000 ffff8686`db388000 : Ntfs!NtfsDecrementCloseCounts+0xf6
fffffa0b`ebd17580 fffff800`16e0a364     : fffffa0b`ebd177f0 ffff8686`db388170 ffff8686`db388010 ffff980b`b8209180 : Ntfs!NtfsCommonClose+0xac2
fffffa0b`ebd17650 fffff800`16e09048     : 00000000`0000001c fffff800`13925440 00000000`00000000 00000000`00000000 : Ntfs!NtfsFspCloseInternal+0x244
fffffa0b`ebd177b0 fffff800`12e52bc5     : ffff980b`ba0cd040 fffff800`12e76070 ffff980b`994d4c00 ffff980b`00000000 : Ntfs!NtfsFspClose+0x88
fffffa0b`ebd17a70 fffff800`12e71d85     : ffff980b`ba0cd040 00000000`00000080 ffff980b`99502080 000fa4ef`b59bbfff : nt!ExpWorkerThread+0x105
fffffa0b`ebd17b10 fffff800`13001ed8     : ffffe081`8e095180 ffff980b`ba0cd040 fffff800`12e71d30 0000000e`0127eaf5 : nt!PspSystemThreadStartup+0x55
fffffa0b`ebd17b60 00000000`00000000     : fffffa0b`ebd18000 fffffa0b`ebd11000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28

SYMBOL_NAME:  Ntfs!ExFreeToNPagedLookasideList+53

MODULE_NAME: Ntfs

IMAGE_NAME:  Ntfs.sys

IMAGE_VERSION:  10.0.19041.2311

STACK_COMMAND:  .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET:  53

FAILURE_BUCKET_ID:  0xc2_99_Ntfs!ExFreeToNPagedLookasideList

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {57ac3e36-a7ac-63e5-8336-417f88ccdab8}

Followup:     MachineOwner
---------

 

Okay with my BlackSquare B58 I've now just completed a 21/2 hr flight from LOWI to EGMC in IMC most of the way and no CTD. Which "workaround" of the many I've tried enabled to complete this I don't know, and I've tried 'em all.  I'm not convinced that it won't happen again.

So far so good. Sample size of two, though!

Loaded in with normal network speed and ReBAR enabled after having previously disabled it due to the SU13 instability. The flight that I loaded, which normally would have yielded a CTD loaded fine. I saw it have the same kind of processing/data exchange kind of issues that had caused CTDs before, but it seems they might have implemented the appropriate error handling this time around with SU14.

Also, I re-enabled the satellite and cloud filters on the World Map and I was able to zoom in, out and move around without feeling the instability of SU13 and without the CTDs.