Fix MSFS crashing when switching to VR by checking OpenXR, add-ons, overlays, VRAM, graphics drivers and unstable CPU, GPU or RAM settings.
Microsoft Flight Simulator usually crashes when switching to VR because the wrong OpenXR runtime is active, an API layer or overlay conflicts, an add-on fails, or the VR transition exceeds GPU or system-memory limits. Restart the VR stack, select the headset’s runtime, disable layers and add-ons, lower VR settings, and test stock hardware settings.
These steps apply to Microsoft Flight Simulator 2020 and 2024 on PC. Xbox has no VR support; MSFS 2020 has no PlayStation version. MSFS 2024 is available on PS5 and PS5 Pro, with PSVR2 support supplied by a free 2026 update, but console VR does not use the Windows OpenXR stack described here.
What should I do first when MSFS crashes on Toggle VR?
Build a clean, low-load VR baseline before reinstalling anything or changing several settings at once.
- Restart the whole VR stack. Close MSFS and the headset software, reboot the PC and restart the headset. For a wired headset, reconnect it directly rather than through an unpowered USB hub. Confirm that tracking and the headset display work before opening the simulator.
- Select the runtime used by the headset connection. Open the software handling that connection and make its OpenXR runtime active. Fully restart MSFS after changing it. Our OpenXR runtime selection and restart procedure covers the headset-specific sequence.
- Disable optional OpenXR layers. Turn off performance overlays, post-processing injectors, recording hooks, foveated-rendering utilities and third-party motion-reprojection layers. MSFS supports OpenXR directly and does not need an OpenVR translation layer.
- Remove other overlays. Temporarily disable graphics-driver overlays, frame counters, monitoring tools and capture software. Closing their windows may not unload their hooks, so switch each overlay off in its parent application.
- Test without add-ons. Select Safe Mode if MSFS offers it after the crash. Otherwise, move the contents of the
Communityfolder elsewhere and disable third-party content where practical. Use a default aircraft, a modest default airport, clear weather and no AI traffic. - Lower the VR graphics profile. Reduce VR render scaling, texture resolution, clouds, terrain level of detail and object level of detail. Lower the settings on the VR page rather than changing only the flat-screen preset, then restart if a setting requires it.
- Return the hardware to stock. Remove CPU and GPU overclocks or undervolts. If the crash remains, temporarily disable XMP or EXPO as a memory-stability test; VR can expose marginal tuning that appears stable on a monitor.
- Enter VR only after the flight has loaded. Start the headset connection first, launch MSFS in 2D, load into the cockpit and then use the assigned Toggle VR command.
Ctrl+Tabis common on the default PC profile, but a customised control profile may use another binding. See our stable launch order and Toggle VR instructions if the normal sequence is unclear.
Once this baseline works, restore add-ons, overlays and runtime features one category at a time. For a large Community folder, restore half at a time; that finds a conflicting package much faster than testing files individually.
Why does MSFS crash only when entering VR?
Entering VR creates a new OpenXR rendering session and sharply increases rendering, video-memory and driver workload even when flat-screen flight is stable.
| What happens | Most likely area | Best first test |
|---|---|---|
| Immediate desktop crash after Toggle VR | Wrong OpenXR runtime, API layer or overlay | Select the intended runtime and disable every optional layer |
| The headset renders briefly, freezes and MSFS closes | Graphics driver or VRAM pressure | Lower VR render scaling and texture resolution, then close GPU-heavy applications |
| VR works in Safe Mode | Aircraft, scenery, toolbar panel or another add-on | Restore third-party content in groups until the crash returns |
| Only one aircraft or airport causes it | That add-on or a location-specific memory spike | Retest with a default aircraft at a default airport |
| The headset is black but the desktop view still responds | Runtime, compositor or display routing rather than a simulator crash | Use the VR black-screen diagnosis |
| The PC restarts, powers off or shows a blue screen | Driver, temperature, memory, power or hardware instability | Restore stock settings and check hardware before reinstalling MSFS |
How do I check for an OpenXR runtime conflict?
The active OpenXR runtime must match the software path that is carrying the headset connection into Windows.
| Headset connection | Runtime to test | Common mistake |
|---|---|---|
| Meta Quest through Quest Link or Air Link | The Meta OpenXR runtime | Starting SteamVR as an unnecessary second VR platform |
| A connection that deliberately launches through SteamVR | The SteamVR OpenXR runtime | Forcing another vendor runtime while the connection depends on SteamVR |
| A wireless application with its own OpenXR route | The runtime selected for that route | Loading its runtime and another OpenXR path together |
| Windows Mixed Reality headset | Windows Mixed Reality on a Windows release that still supports it | Trying to repair removed WMR support through an MSFS setting |
The store from which MSFS was purchased does not decide the runtime. A Steam copy of MSFS does not automatically require SteamVR, and a Microsoft Store copy can still use a SteamVR-based headset route.
Windows selects one active OpenXR runtime, but several API layers can still load around it. A mistake we see constantly is changing the runtime while leaving the old toolkit, overlay or injector active in the background. Disable those layers and restart every part of the VR stack before judging the result.
Could VRAM or the graphics driver be causing the crash?
A driver or memory-pressure fault is likely when the headset begins rendering before freezing, when demanding airports fail but simple locations work, or when Windows records a display-driver reset.
- Reduce VR render scaling first. It directly cuts the headset render target. Texture resolution, terrain level of detail and object level of detail are the next useful reductions for a high-detail aircraft or airport.
- Close GPU-heavy applications. Browsers playing video, recording software, image tools and other 3D applications consume memory that MSFS may need during the transition.
- Reinstall the display driver cleanly. Use the clean-install option if the graphics installer provides one, then reboot. If the crashes began immediately after a driver update, test the previous stable driver available for that GPU.
- Test DirectX 11 in MSFS 2020. If the 2020 edition crashes under DirectX 12, DX11 is a useful isolation test. Do not search for this switch in MSFS 2024, which uses its supported DirectX 12 path.
- Keep the Windows page file system-managed. Disabling it can turn combined RAM and VRAM pressure into an application crash. Its drive also needs adequate free space.
- Check the physical connection. If a wired headset disconnects at the same moment, try another suitable motherboard USB port and inspect the headset cable. A runtime losing the device can resemble an MSFS crash.
High VRAM use by itself does not prove that the GPU is unsuitable. The stronger evidence is repeatability: the crash disappears at lower render scale or texture resolution and returns when those settings are raised.
How can I identify which component crashed?
Windows Reliability Monitor and Event Viewer can show whether the failure came from MSFS, an OpenXR layer, the graphics stack or the wider system.
- Search Windows for
View reliability historyand open the failure recorded at the time of the crash. - Record the faulting application, faulting module and exception code rather than relying only on the red failure marker.
- Check
Event Viewer > Windows Logs > Applicationfor the MSFS crash andWindows Logs > Systemfor display-driver resets, hardware errors or an unexpected restart.
A headset-runtime or overlay module points towards that component. A graphics-driver module or a related LiveKernelEvent supports investigating the driver, GPU stability and power, although it does not by itself prove defective hardware. The main simulator executable as the faulting module is generic and does not identify the underlying cause.
If the machine restarted, an Event 41 entry only confirms that Windows shut down unexpectedly; it does not explain why. Temperatures, power delivery, RAM stability and CPU or GPU tuning then matter more than reinstalling the simulator.
What if the crash still does not improve (改善しない)?
If the clean baseline still crashes, classify the fault by what else fails instead of repeating the same graphics changes.
- MSFS also crashes in 2D: the issue is not limited to OpenXR. Follow our clean non-VR crash-isolation process for damaged files, caches, add-ons, drivers and hardware instability.
- Every PC VR application fails: repair the headset connection software, runtime, firmware or graphics driver before changing MSFS again.
- Only one aircraft or location fails: remove that package and its dependencies. Rolling cache or streamed world data is worth testing only when the crash is location-specific, not when every Toggle VR attempt fails.
- Only MSFS fails with no add-ons or layers: reset the simulator’s VR graphics settings, repair the headset runtime and verify the simulator application files through its launcher platform.
- A Windows Mixed Reality headset stopped after a Windows upgrade: check whether that Windows release still includes WMR. MSFS settings cannot restore a platform component removed from Windows.
Should I reinstall Microsoft Flight Simulator?
A complete MSFS reinstall should be the final step because most Toggle VR crashes originate in the runtime, graphics driver, optional layers, add-ons or unstable hardware settings.
Repair or reinstall the headset software first, reset the VR graphics profile, remove Community content and use the launcher platform’s file-verification or repair function. Do not manually delete the Official package folder as an early test; doing so can trigger a very large content download without replacing the conflicting OpenXR component.
Consider a full reinstall only after the clean baseline still fails, file verification reports damage or the simulator cannot remain stable in 2D. Preserve any required control profiles and confirm where the large content packages are stored before removing the installation.