Fixed “big” size is best IMHO and cleared every time you shut down.
What would you recommend as a paging file size with 32GB of physical RAM? I have never had CTDs in MSFS, but would like to optimize my paging file, since my MSFS computer is pretty much dedicated just for flight sim use.
Unstable overclocks or mods. 99% of them.
Not smart nor necessary. Not sure if you think that basic security best practices are somehow going to mess with the sim.
I run my Windows 10 (soon to be Windows 11) machine with the firewall enabled, with Defender enabled for real time scan and I do on demand scans weekly. I exclude the MSFS process, and have had zero CTDs or other issues.
No offense, but it amazes the lack of technical knowledge and almost “computer voodoo” we see, that users think prevent issues. It’s like saying “I left the front door to my house wide open, with my cash sitting on the table, and I haven’t had any house fires…not one.”
I have 32GB ram, and because I have two 1TB SSD drives, I set a 32GB Page file on the non OS drive, and set it fixed at 32GB (and have Windows clear it when I shut down, so it is always "empty when I restart FS)
This was more important back in the days of Rotating Drives ( access time, fragmentation etc), so I don’t know how much you gain with a SSD, but I am assuming having the Swap Drive on the non-Os drive, may still be an advantage.
I am always open to other suggestions or comments 
1 Like
I can report two CTD’s this week… unusual for me… both occured when returning to main menu. One was after landing somewhere in the wild, second was after Nice landing challenge. The CTD came within seconds of clicking the option. No wait screen with blue progress bar was presented.
did you get Crash Dumps ??
Without those, its just a random Guessing game
1 Like
You need a full memory CRASH DUMP, that you can run an analysis program on like Windbg, to show the exact instruction that cause the CTD, what memory /registers were at that time, and the surrounding assembly code.
All that CRASH event shows is that you had an unhandled attempt to access invalid memory (Typically a Null pointer being the cause)
But this is not something that the App “USER” should have to worry about, or need to deal with or investigate.
Its FLIGHT SIMULATOR, not a “Windows Game DEBUG Simulator”
Current settings as below for the memory dump, but I don’t see any \Windows\memory.dmp or similar. I think the file was cleared already, the above is 2 days ago.
Let’s put a manual to enable Crash dump here… first use System, then go Advanced System settings then go Startup and Recovery… there’s a checkbox ! I think it’s better to keep the file (check the second one also)
Typical analysis (That user ca do from a Crash dump)
96cc0bb 0f1f440000 nop dword ptr [rax+rax]
00007ff6`996cc0c0 0fb601 movzx eax, byte ptr [rcx]
00007ff6`996cc0c3 33c2 xor eax, edx
00007ff6`996cc0c5 69d093010001 imul edx, eax, 1000193h
00007ff6`996cc0cb 48ffc1 inc rcx
00007ff6`996cc0ce 488d44243c lea rax, [rsp+3Ch]
00007ff6`996cc0d3 483bc8 cmp rcx, rax
00007ff6`996cc0d6 72e8 jb FlightSimulator!FlightSimGetProcessId+0x66f320 (00007ff6`996cc0c0)
00007ff6`996cc0d8 0fb6c2 movzx eax, dl
00007ff6`996cc0db 498d34c2 lea rsi, [r10+rax*8]
00007ff6`996cc0df 488b8648a20800 mov rax, qword ptr [rsi+8A248h]
00007ff6`996cc0e6 488bd8 mov rbx, rax
00007ff6`996cc0e9 4885c0 test rax, rax
00007ff6`996cc0ec 7422 je FlightSimulator!FlightSimGetProcessId+0x66f370 (00007ff6`996cc110)
00007ff6`996cc0ee 8b4c2434 mov ecx, dword ptr [rsp+34h]
00007ff6`996cc0f2 8b542430 mov edx, dword ptr [rsp+30h]
00007ff6`996cc0f6 3910 cmp dword ptr [rax], edx
00007ff6`996cc0f8 750a jne FlightSimulator!FlightSimGetProcessId+0x66f364 (00007ff6`996cc104)
00007ff6`996cc0fa 394804 cmp dword ptr [rax+4], ecx
00007ff6`996cc0fd 7505 jne FlightSimulator!FlightSimGetProcessId+0x66f364 (00007ff6`996cc104)
00007ff6`996cc0ff 397808 cmp dword ptr [rax+8], edi
00007ff6`996cc102 742f je FlightSimulator!FlightSimGetProcessId+0x66f393 (00007ff6`996cc133)
line 00007ff6`996cc0df 488b8648a20800 mov rax, qword ptr [rsi+8A248h]
caused the CTD, but without a symbol table, or the source code, trying to determine exactly WHY this happened is a “Major Challdenge”
In some case, (Not like this one), it can be more obvious…
1 Like
Nice…the real detailed information 
I haven’t looked at x86 assembly for 35 years to be honest… with above disassembly without the labels - without debug info - there’s very little to tell about what it means.
Yes, also about 20 years since I got into this sort of Technical detail in debugging Windows code !! (Days of FSX development)
I have a 100% every time CTD, when I plug in Thrustmaster “Top Gun” FF Joystick.
In this case, the Crashdump clearly show MSFS having trouble reading the days from the Joystick, so it is somewhat clearer, where the issue is… but still since it is a call to a MS dll, its really impossible for the user to get any deeper into it.
The specific MS dll is not present on a ms symbol server? Maybe set the nt_symbol env path (i don’t remember well anymore)
Edit:
ping @N6722C (ping as post does not show as a reply)
1 Like
Did not see it, indeed… ok allow me to insert a remark…
For C/C++ runtime versions and MFC base libraries there is lots of files. You get them with Visual Studio. But there are also many DLL’s that are part of MSFS itself. If MS/Asobo would publish their debug info, they would give away large part of their code. Assembly with debug info can be disassembled into C with the proper variable names 
1 Like
Oh so true.
Crap, i need to be more clear in some answers. it was in a response to
Edit: as in response to @ArcanePython931 dumps have stack traces, which kind of possible help with identifying, like here: Why do some have CTDs and Others do not? - #131 by scriptkid (couple posts above). Often just a quick glance can already show the obvious (in my case it did )
But again, like @N6722C is saying. It’s not our job.
but, it “could” be , if you REALLY wanted it to be … (and they could afford you !! )
Anyone know anyone who has joined Asobo since MSFS launch ??
2 Likes
Just want to chime in that I’m loving this thread. Like many of you, I haven’t done debugging work like this in 20 years. Sucks getting old.
For me, I’m on a gaming laptop, and I ONLY get CTDs when I exit a flight. Everything else about the flight is fine. Only when landing, going back to the main menu does it CTD. So doesn’t feel like power, driver, addon. Oh, and exiting the flight at different points (on ground, in air, running, not running) doesn’t make any difference.
Plus I didn’t get CTDs with any other MSFS version. And I haven’t changed a single thing in terms of HW. Just normal driver updates. Go figure.
Thanks again for all the great detail and insight!!
1 Like
Remarkable. Exception code 0005 too ? Can you post the reliability monitor screenprint… Above I posted two of these, same situation, back to main menu… it seems MSFS sometimes crash, when memory is released ? They did work on memory stuff… I wonder if something goes wrong with a null pointer being freed 
that was the error I always made… with unmanaged code…
Yeah - exception code 0005 always. I looked at my reliability monitor, there’s nothing really there. It doesn’t seem to even pick up the MSFS CTDs (LOL).
All of the red errors are not related to times I was flying, the 2 sets on the left were “Windows was not properly shutdown” (which I’ve never done). Last one is the Razer GamingManager service (again, not while I was flying).
