Find Microsoft Flight Simulator crash logs in Windows, interpret faulting modules and exception codes, and isolate the real cause without guesswork.
Microsoft Flight Simulator does not keep one complete, human-readable crash log. On PC, note the crash time, then check Windows Reliability Monitor and Event Viewer for the matching application failure. Use the faulting module, exception code and repeated crash pattern as clues, then confirm the cause with one controlled change at a time.
Where do I find Microsoft Flight Simulator crash logs?
On PC, the two most useful starting points are Reliability Monitor and the Application log in Windows Event Viewer. These records are separate from the simulator's installation and Community folders, so the process is the same for Microsoft Store and Steam installations.
- Record the crash time and circumstances. Note the aircraft, airport, flight phase, weather, peripheral being used and the last action before the crash. The exact time lets you distinguish the relevant event from unrelated Windows errors.
- Open Reliability Monitor. Search Windows for
View reliability history, or press Windows+R and runperfmon /rel. Select the day and time of the crash, open the Microsoft Flight Simulator application failure, and choose the option to view its technical details. - Check Event Viewer. Press Windows+R, run
eventvwr.msc, then openWindows LogsandApplication. Inspect entries at the recorded time, especially anApplication Errorevent, commonly ID 1000, and a nearbyWindows Error Reportingevent, commonly ID 1001. Our detailed Event Viewer filtering walkthrough explains how to locate the right entry without being distracted by unrelated warnings. - Look for Windows Error Reporting files only if needed. Archived reports may appear under
C:\ProgramData\Microsoft\Windows\WER\ReportArchiveorReportQueue. A dump may appear under%LOCALAPPDATA%\CrashDumps, but only when Windows created one for that crash. Dumps need debugging tools and are not readable as ordinary text.
Folder visibility and reporting settings affect what Windows retains. Our map of the Windows locations containing MSFS crash evidence covers the available report and dump folders in more detail.
Which crash-log fields actually matter?
The crash time and any repeatedly named faulting module are usually the most useful fields. A single exception code or Windows DLL is only a lead, not a diagnosis.
| Crash-log field | How to use it |
|---|---|
| Application name and time | Confirm that the event belongs to Microsoft Flight Simulator and matches the crash you are investigating. |
| Faulting module name and path | Look for the same specific driver, add-on component or executable across several crashes. One appearance can be incidental. |
| Exception code | Use it to classify the failure broadly. It rarely identifies the responsible add-on or hardware component by itself. |
| Fault offset | Useful to developers comparing identical builds, but generally not actionable for an end user. |
| Fault bucket or report ID | Helps correlate reports of the same failure, but a bucket name should not be treated as the root cause. |
A recurring graphics-driver module points towards the display-driver or GPU path. A module belonging to a third-party aircraft, utility or scenery package makes that component the first item to remove and retest. If the module changes from crash to crash, system instability, memory corruption or multiple unrelated failures become more plausible.
A mistake we see constantly is assuming that ntdll.dll, KERNELBASE.dll or ucrtbase.dll must be replaced because Event Viewer names it. These are common Windows components through which an application failure is reported; the actual trigger may still be an add-on, driver, unstable overclock or corrupted data.
How do I use the log to isolate the cause?
Use the log to choose the next controlled test, then reproduce the same flight rather than changing several settings at once. We treat the log as evidence pointing towards a test, never as the final verdict.
- Create a repeatable case. Load the same aircraft, airport, runway and weather conditions that preceded the crash. If the failure cannot be repeated, collect evidence from several crashes before drawing a conclusion.
- Establish a clean baseline. Use Microsoft Flight Simulator's Safe Mode when it is offered after a crash, or temporarily move Community content out while the simulator is closed. Test a default aircraft at a default airport.
- Follow the strongest clue. For a recurring graphics module, return the GPU, CPU and RAM to factory settings and test the display-driver path. For a specific add-on module or location, remove that package. For an online-only failure, disable one online data feature at a time.
- Change one variable. Repeat the same test two or three times after each change. A single successful flight does not prove that an intermittent crash has gone.
- Restore content methodically. If the clean baseline works, reintroduce add-ons in batches. When the crash returns, divide the suspect batch and test again until one package or interaction remains.
If the evidence remains inconclusive, follow our controlled MSFS crash-isolation sequence for add-ons, drivers, cache, memory instability and repeatable flight conditions.
What if Event Viewer only shows ntdll.dll or 0xc0000005?
A generic Windows module or 0xc0000005 access-violation code does not identify the culprit. It means the process attempted an invalid memory access, which can result from an add-on defect, damaged data, a driver problem or unstable CPU, GPU or RAM settings.
Do not download replacement DLL files or reinstall Windows based on that entry alone. First test Safe Mode, default content and factory clock settings. If crashes continue without add-ons and across different aircraft and locations, check system memory, temperatures and drivers before blaming a particular scenery or aircraft package.
What if there is no MSFS crash entry?
No Application Error usually means Windows did not record an ordinary crash-to-desktop. A freeze terminated through Task Manager, a graphics-driver reset, a blue screen or a complete PC restart can leave different evidence.
Check Reliability Monitor for LiveKernelEvent or hardware-error entries, then inspect the Event Viewer System log around the same time for display-driver, WHEA or unexpected-shutdown events. Kernel-Power event 41 only confirms that Windows shut down unexpectedly; it does not reveal why.
If Microsoft Flight Simulator remains running on a loading screen, treat that as a hang or loading failure rather than a logged crash. Use our loading-screen troubleshooting process to isolate aircraft, scenery, cache and streaming problems.
Can I access MSFS crash logs on Xbox or PlayStation?
Xbox and PlayStation do not expose Event Viewer or user-readable crash dumps. For Microsoft Flight Simulator on Xbox Series X|S, and MSFS 2024 on PlayStation 5 or PS5 Pro, diagnosis relies on reproducing the failure with a default aircraft and airport, disabling optional content involved in the crash, and recording the exact trigger.
Microsoft Flight Simulator 2020 is not available on PlayStation. Console telemetry may be collected by the platform and simulator, but users cannot inspect it in the same way as Windows crash records.