Seems a bit of a kick in the teeth for the FSDreamTeam and their release of GSX.
Not saying that GSX is without its own issues, but I suspect a lot of GSX-blamed CTDs are the result of what’s been going on across the board this weekend.
Its a bit of a shame, and has probably resulted in a lot of stalled sales.
thanks, got it now
Friday US West Coast C172 (Low load on machine) CTD with RAM error as seen above.
Yesterday evening 2 CTD’s with FBW A32NX in Stockholm area (EDDH-ESSB)
Today LIVE WEATHER TURNED OFF in data menu I could finish my flight EDDH-ESSB.
So far so good…
Do you have any mods installed? If so, which one(s)?
Plenty, didn’t have any issues till the weekend. Nothing new.
What plane were you flying?
Milviz C310R
What were your departure and arrival airports?
EDLE → EDDC
Did you have live weather enabled?
yes
Did you have live traffic enabled?
no
Are you on SU9 or SU10 beta?
SU9
Are you using DX11 or DX12?
DX 11
What is your GPU and what driver version are you using?
GeForce 1050Ti, current drivers
Are you on Windows 10 or 11?
Win10
Is anyone getting these crashes on SU10?
yes, me, all the time
Ok so it’s not an SU9 issue. I haven’t had a single crash yet on SU10 since these were reported.
I hope it’s solved for you all.
SU9 or SU10 beta, doesn’t make a difference. This weekend has been a nighmate with CTDs.
It’s unacceptable, a game breaking issue, and we need a fix, or at least a formal acknowledgement. Yesterday.
yes we are
SeedyL posted and also the tag “feedback-logged” was added. How much more acknowledgement do you expect on a Sunday without clear clues on what the reason is?
There are several different crashes going being described in this thread and while it is possible that they all are related by root cause they are at face value different issues. It isn’t clear from this thread whether there really is a significant problem that just has materialized because most of the comments aren’t strictly useful towards identifying a single issue. The best thing anyone who is experiencing problems can do is post their Event Viewer logs to this thread. That will provide some indication here as to whether there is a widespread issue that can be addressed. The next best thing is to post as many details you can about your environment, what you were doing when the crash occurred, etc. If this is an issue that is some sort of component problem that can be addressed on the end-user side, doing this may help isolate the cause. Without Event Viewer logs though, it is impossible to know whether a given report is the same issue that others are experiencing.
The first thing that is interesting in the Event Viewer log is the Exception code. Exception code: 0xc0000005 is an access violation, which means MSFS tried to access an addres in a page of memory that didnt’ belong to it. For those who are experiencing that issue, the address being accessed is important. Some are seeing attempts to access 0x00000000, which is never going to be a valid address. Usually, this error occurs because code is assuming that it is getting a valid address, so it doesn’t bother to check. Sometimes identifying the root cause of the problem can be non-trival.
Others are crashing with 0xc0000005 on attempts to access 0xFFFFFFFF. As someone earlier pointed out, in decimal this is -1. These crashes are typically caused by overflow/underflow errors where integral values wrap around. In any case, this is a different issue.
Exception code: 0xc0000374 is heap corruption, which is yet another issue. In that case, a legitimate block of memory allocated in the application has been stomped on.
As far as reports with the same Exception code go, they are only definitively the same issue if, in addition to having both the same Exception code (and in the case of memory exceptions, the same memory address) they also have the same Fault offset. The Fault offset identifies the memory address of the instruction that caused the issue relative to the memory location where the application was actually loaded. If the Fault offset is different, it is a different crash. The one caveat here is that if different versions are being used (i.e. beta vs ship), there is no way of knowing from the Event viewer log alone whether the crashes reflect the same issue.
Additionally, the Faulting application name and Faulting module name must match. If the call stack is different, it is technically a different crash, but more than likely it is the same root cause. A crash in module ntdll.dll is not the same as a crash in module flightsimulator.exe.
As I said, if you want to help Asobo, pasting the event log is the most useful thing that can be done in this thread. What Asobo can do with that information is locate the line of code that is generating the exception, which will hopefully allow them to hypothesize about the cause of the crash in order to track it down. They can locate the line of code either by just loading MSFS up in the debugger, or they can use the /LINK switch to generate a map file which will correllate the offset to code.
That said, unless this thread coalesces into a whole bunch of people reporting the same event log, I doubt this is going to gain much traction. If something changed on a server, I’d expect bug report numbers commensurate with usage. Speaking of which, if your event log contains a bucket number, then the crash has been reported at least to Microsoft. If Asobo has access to that data, then they will already know if there is a major crashing bug in the wild.
Do you have any mods installed? If so, which one(s)?
Lots, but nothing has been updated recently.
What plane were you flying?
Fenix, 414AW
What were your departure and arrival airports?
WBKK to VVTS 2x, EGPF no destination planned.
Did you have live weather enabled?
Yes
Did you have live traffic enabled?
Yes
Are you on SU9 or SU10 beta?
SU9
Are you using DX11 or DX12?
DX11
What is your GPU and what driver version are you using?
2070, up to date.
Are you on Windows 10 or 11?
Win10
Well I managed a few 30 minute flights today without a crash then it just suddenly did it about 5 mins into a flight. Seems to always happen as I’m moving the camera around quickly. Could be another coincidence though.
Really interesting breakdown. However I think there is no denying the fact that something must have changed on Asobos end if this many people are having some form of CTD that is massively out of character for their sim.
Just got another CTD, this time with Live Weather disabled (in Data options). Updated my report above.
May be a red herring. My latest CTD was a test I basically flew in the 414AW for EGPF. Runway 23, then heading 135 and FL200 set.
I let it fly, with no other interaction (other than initial MP and Prop adjustments for cruise)
1 1/2 hour in, the tell-tale sound stutter and CTD over the English Channel.
Not sure what the reason is. Just finished my first flight without CTD in a while, disabled live wheather in the General Options → Data section.
yep, therefore is the topics heading changed to “ntdll” . Thats what we expect that it is the “new” issue ( " ntdll.dll / 0xc0000374 " / also because all point to same error-offset ). Thats seemingly the only relevant error which users get, which since ‘years’ never seen a CTD. ( for the “memory…” issue is another topic )
@Baracus250
yes,.. the issue is not realy reproducable at same position / same amount of time in air. I fly the same route and it ctd at realy different places.
Currently I’am again in the air, same route.. I found an intressting post within the P3D forum with exact same error and user reported “remove shaders” was helpfull. So, that I did and now I exiding what will happen… ( I’am realy not sure about that, but who knows )
Hello @Majjistral,
Members of the CM team (myself and my colleague @Jummivana) posted in this thread multiple times yesterday. The topic itself has been tagged with feedback-logged. I have been reading every reply in this topic and am closely monitoring the situation. We have also escalated this issue internally to our support teams.
Thanks,
MSFS Team
Hard to say. Something may have changed for the people getting crashes, but there isn’t enough data yet to know what and whether there is a single, widespread issue that is affecting people. There are lots of moving parts–even with MSFS itself and things are always getting updated locally. The X-Box architecture (on the PC) is nightmare of services and device drivers that all can contribute to these kinds of issues and ntdll.dll is a wrapper for system calls, so I’d be looking for a lower-level cause for those issues. Plus you have Windows updates and video driver updates in the mix. Way too many moving parts to easily track down. I’m not experiencing CTDs at the moment (even with GSX, FSUIPC and a whole bunch of other add-ons), but I feel for the folks that are. There are no good ways available to the end user to track these problems down.