Find MSFS 2020 and MSFS 2024 crash logs in Event Viewer, Reliability Monitor and WER, then interpret modules and codes without false diagnoses.
Microsoft Flight Simulator 2020 and MSFS 2024 do not keep one complete, readable crash log. On Windows PC, find crash evidence in Reliability Monitor, Event Viewer’s Application log, Windows Error Reporting folders and, if enabled, local crash dumps. Console users cannot access these records. Always match entries to the failure time.
Where are Microsoft Flight Simulator crash logs stored?
Windows stores the useful MSFS crash records rather than the simulator itself.
| Crash evidence | Location | What it contains |
|---|---|---|
| Event Viewer | Windows Logs > Application | Event time, application name, faulting module and exception code. Its database is %SystemRoot%\System32\winevt\Logs\Application.evtx, but read it through Event Viewer rather than opening or modifying the file. |
| Reliability Monitor | Search for View reliability history, or run perfmon /rel | A chronological view of application failures, hangs, Windows problems and hardware errors. |
| Windows Error Reporting | %LOCALAPPDATA%\Microsoft\Windows\WER\ and %PROGRAMDATA%\Microsoft\Windows\WER\ | Check ReportArchive and ReportQueue for retained Report.wer files and associated dumps. |
| Local crash dumps | %LOCALAPPDATA%\CrashDumps | Binary .dmp files, but only when Windows or the application has been configured to create them. They require debugging tools and are not text logs. |
These MSFS 2020 and MSFS 2024 crash log locations are the same for Microsoft Store and Steam installations. Package locations differ, but the Community and Official folders contain simulator content, not Windows crash reports. WER folders can be hidden, empty, automatically purged or unavailable without administrator permission.
The Developer Mode Console can reveal package errors while Microsoft Flight Simulator is running. It is not a dependable post-crash log because its contents normally disappear when the simulator closes.
How do I find the correct MSFS crash in Event Viewer?
Find the correct event by matching it to the exact time Microsoft Flight Simulator failed, then compare its signature with later crashes.
- Record the time and circumstances. Note the hour and minute, aircraft, airport, flight phase, weather, peripherals and the last action before the failure.
- Open Reliability Monitor first. Run
perfmon /relor search forView reliability history. Select the relevant date and open the Microsoft Flight Simulator failure’s technical details. - Open Event Viewer. Press
Win+R, entereventvwr.mscand openWindows Logs > Application. - Filter a short period. Use
Filter Current Logto show Error and Critical events from the hour surrounding the crash. Do not assume the newest Windows error belongs to MSFS. - Find the simulator event. Look for an
Application Errormatching the crash time and Microsoft Flight Simulator executable. Event ID1000is common, but Windows does not use it for every failure. - Check Windows Error Reporting. A related WER event, commonly ID
1001, may follow. WER records can be logged at Information level, so adjust or clear the severity filter if they are hidden. - Read the complete details. Record the application, module and their paths, exception code, event time, report ID and fault bucket. The Details tab’s XML view may expose fields omitted from the General summary.
- Inspect the System log when needed. If the display driver reset, Windows froze or the PC restarted, check
Windows Logs > Systemat the same minute for display-driver,WHEA-Loggeror unexpected-shutdown events.
What should I save from Event Viewer?
Save the matching events and identifying fields rather than exporting the entire Windows log. Right-click an event to copy its details as text, or use Save Selected Events to create an .evtx file.
Keep paired Application Error and Windows Error Reporting records where available. Check them before sharing: event data and dumps can expose Windows usernames, account details and personal folder paths.
Which MSFS crash-log fields actually matter?
The failure time and a module repeated across several crashes are more useful than one isolated exception code.
| Crash-log clue | Meaning and next test |
|---|---|
| Application name, path and time | Confirms that the record belongs to Microsoft Flight Simulator and matches the failure under investigation. |
| Same external module repeatedly | The aircraft component, utility, overlay, plug-in or driver owning that module becomes a strong suspect. Disable or update it, then repeat the same flight. |
0xc0000005 | An invalid memory access. Add-on defects, damaged data, drivers and unstable CPU, GPU or RAM settings can all cause it. |
0xc0000409 | A fail-fast termination. It describes how Windows stopped the process, not which component created the bad state. |
0xe06d7363 | An unhandled Microsoft C++ exception. It is too broad to identify a responsible package by itself. |
ntdll.dll, KERNELBASE.dll or ucrtbase.dll | The failure surfaced through a Windows runtime component. The named Windows file is not necessarily damaged or responsible. |
| Graphics-driver module or display reset | Points towards the display-driver or GPU path. Remove GPU tuning, test a stable driver and reduce unusually heavy graphics or VRAM demands. |
| Fault offset, bucket or report ID | Useful for correlating identical failures or comparing the same simulator build, but it rarely establishes the root cause for an end user. |
A mistake we see constantly is treating one Event ID 1000 module as a verdict. If the named module changes between crashes, wider system instability, memory corruption or several unrelated failures become more plausible. Never download replacement DLL files based solely on an ntdll.dll or similar entry.
If the crash happens while entering or leaving VR, compare the Application and System events using our checks for separating simulator, headset-runtime, overlay and display-driver failures.
Why is there no MSFS crash report or dump?
Windows does not create or retain an application report for every type of failure.
- An ordinary crash to desktop may leave only an Event Viewer entry.
- Windows may have purged the WER report, or error reporting may be restricted.
%LOCALAPPDATA%\CrashDumpsmay not exist until local dump collection has been enabled.- A hard lock, power loss or abrupt restart may leave no Application event. Check Reliability Monitor for
LiveKernelEventand the System log for hardware or driver errors. Kernel-Powerevent 41 confirms that Windows did not shut down cleanly; it does not identify the power supply or any other component as the cause.- An in-simulator reporting prompt may send telemetry without retaining a readable local copy. Record any reference number it displays.
Do not enable full dumps casually. They consume substantial storage and can contain account names, local paths or other private information.
If Microsoft Flight Simulator remains visible but stops progressing, it is a hang rather than a normal crash to desktop. Use our checks for distinguishing and troubleshooting an MSFS hang; hangs and loading-screen freezes can produce different records or none at all.
Is an aircraft crash recorded in Windows?
No. Striking terrain, overstressing the airframe or triggering MSFS crash detection is a gameplay event, not an application failure. It may show an in-simulator message, but it does not create a Windows crash report.
How do I use an MSFS crash log to isolate the cause?
Treat the record as evidence for the next controlled test, not as a final diagnosis.
- Create a repeatable case. Load the same aircraft, airport, runway, weather and flight phase. Collect several records before judging an intermittent problem.
- Establish a clean baseline. Use Safe Mode when MSFS offers it, or move Community content out while the simulator is closed. Test a default aircraft at a default airport.
- Follow the strongest clue. Remove a consistently implicated add-on or overlay. For graphics or WHEA events, return CPU, GPU and RAM settings to factory defaults and test the driver and hardware path.
- Compare aircraft and scenery. If one aircraft, livery or airport triggers the crash, repeat the location with default aircraft and scenery. When an aircraft or avionics package is implicated, follow our WASM add-on crash checks.
- Change one variable. Repeat the same flight two or three times after each adjustment. One successful flight does not prove that an intermittent crash is fixed.
- Restore content methodically. Reintroduce add-ons in batches. When the crash returns, divide the suspect batch and retest until one package or interaction remains.
For inconclusive or random crashes, use our controlled MSFS troubleshooting order for add-ons, caches, drivers and hardware stability. Reinstalling the whole simulator should follow targeted tests, not replace them.
Can I access MSFS crash logs on Xbox or PlayStation?
No. Xbox Series X|S, PlayStation 5 and PS5 Pro do not expose Event Viewer, WER folders or user-readable crash dumps.
Record any on-screen error code or report reference, then reproduce the failure using a default aircraft and airport with optional content disabled where possible. Microsoft Flight Simulator 2020 is available on PC and Xbox only; Microsoft Flight Simulator 2024 is also available on PlayStation 5 and PS5 Pro.