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.
)