Microsoft Flight Simulator 9 min read 2.1k views

How do I fix “Limited by main thread” in MSFS 2024?

Ian Stephens
In short

Fix “Limited by main thread” in MSFS 2024 by comparing MainThread, graphics-queue and GPU times, then changing the settings that matter.

“Limited by main thread” means MSFS 2024’s MainThread has the highest frame time; “Limited by graphics queue” points instead to the render-submission queue. Neither message is an error by itself. Use the native frame-time display, identify the sustained highest timing—MainThread, graphics queue/render or GPU—and tune that subsystem first.

How do I show frame times in MSFS 2024?

On PC, Developer Mode provides the native FPS and frame-time display needed to diagnose the limit rather than guess from overall FPS or CPU utilisation.

  1. Enable Developer Mode. Open MSFS 2024 Settings, find Developer Mode in the General or advanced options and switch it on. The settings search is the quickest way to find it if an update has moved the option.
  2. Open the FPS display. Load a flight, use the Developer Mode menu bar at the top of the screen and select Options > Display FPS. Some interface revisions group the equivalent FPS command under Debug. Our Developer Mode instructions explain the toolbar and performance display in more detail.
  3. Remove pacing controls temporarily. Disable V-Sync, external frame caps and frame generation while measuring. These can hide the native rendered frame rate or introduce intentional waiting.
  4. Run a repeatable test. Use the same aircraft, airport, cockpit view, weather and time of day. Let initial loading settle, then observe a representative section of the flight rather than a single spike.
  5. Compare milliseconds, not just FPS. The stage with the highest sustained frame time is holding up the frame. About 16.7 ms is the budget for 60 rendered fps; 33.3 ms is the budget for 30 rendered fps.

Watch MainThread, the graphics-queue or render timing, and GPU. A brief spike while changing view, loading terrain or approaching an airport is not the same as a sustained bottleneck. External CPU, GPU and VRAM readings can provide supporting evidence, but the simulator’s own frame-time display should lead the diagnosis.

MSFS 2024 limited by main thread: what does it mean?

A sustained Limited by MainThread status means the main CPU simulation thread is taking longer than the other measured stages to prepare the next frame. Microsoft Flight Simulator 2024 uses multiple cores, but flight-model calculations, traffic, avionics, scenery preparation and other dependent tasks still have to be coordinated through a main thread.

This is why overall CPU utilisation can look modest while MSFS is main thread limited. One logical processor may be heavily occupied while other cores have spare capacity. Task Manager showing 40% total CPU utilisation does not rule out a MainThread bottleneck.

The message also does not mean anything is broken. Every frame has a slowest stage, and a powerful system can still become MainThread-limited in a complex airliner at a detailed airport with dense traffic.

What does “Limited by graphics queue” mean in MSFS 2024?

“Limited by graphics queue” means frame completion is being held up in the graphics command-submission and synchronisation path between the simulator’s rendering work and GPU execution. It is distinct from a MainThread limit, and it should not automatically be treated as proof of a GPU bottleneck.

The graphics queue contains rendering commands and resources prepared for GPU execution. It can become the longest stage because the GPU is taking too long to drain queued work, but it can also wait on driver operations, resource transfers, VRAM paging, shader compilation, presentation synchronisation or software that hooks into the rendering pipeline.

  • MainThread limit: the CPU’s simulation and frame-preparation work is the sustained longest stage.
  • Graphics-queue limit: the render-submission or queue path is delaying completion; the GPU may or may not be the underlying cause.
  • GPU limit: the GPU execution time is the sustained longest timing and rises predictably with resolution or graphics quality.

Use the relationship between the counters. If graphics-queue and GPU times rise and fall together, and GPU time is as high as or higher than the other stages, treat it as a GPU workload problem. If the queue/render timing remains high while GPU time is clearly lower, investigate the submission path, driver, VRAM and rendering hooks before reducing every graphics setting.

How should I troubleshoot a graphics-queue limit?

  1. Confirm it in the same test flight. Remove V-Sync, frame caps and frame generation, then verify that the graphics-queue status is sustained rather than a momentary loading spike.
  2. Check the GPU relationship. If GPU time tracks the queue time, reduce resolution or render scale, clouds, shadows, reflections and other GPU-heavy effects. Monitor VRAM as well; texture and resource pressure can produce queue stalls before average GPU utilisation reaches 100%.
  3. Remove rendering hooks. Disable recording overlays, performance overlays, ReShade-type injectors and other utilities that attach to the graphics pipeline. Return GPU and VRAM overclocks or undervolts to stock settings for the test.
  4. Test one display and one view. Close detached instruments and additional render windows. Independent views and extra displays create more rendering and submission work; our multi-monitor performance checks cover this specific failure mode.
  5. Refresh the driver path. Restart the simulator and PC, then install or reinstall a suitable stable graphics driver if the problem began after a driver or simulator update. Resetting a shader cache is a later step because it causes temporary recompilation stutter.
  6. Exclude content problems. Test with an empty Community folder and a default aircraft. A damaged asset, unusually heavy scenery package or aircraft display can create resource-upload and rendering stalls that look like a general queue problem.

Which settings should I change for each limit?

Choose settings by the sustained highest frame time. Lowering unrelated settings often reduces image quality without addressing the actual delay.

Sustained limitHow to confirm itChange these firstDo not start with
MainThreadMainThread time is consistently highest, especially around cities, airports, traffic or complex aircraft.Terrain LOD, Objects LOD, AI/live traffic, airport activity, aircraft systems, glass-cockpit refresh rate where available, add-ons and background applications.Resolution, anti-aliasing or texture quality unless GPU or VRAM is also constrained.
Graphics queue/renderQueue or render timing is highest. GPU time does not necessarily match it.Check GPU correlation, VRAM pressure, overlays and injectors, extra views, driver state, shader compilation and problematic aircraft or scenery assets.Assuming it is a CPU MainThread problem or blindly reducing Terrain LOD.
GPUGPU frame time is consistently highest and responds to changes in resolution or graphics quality.Resolution, render scale or upscaling mode, clouds, shadows, reflections, ambient occlusion and other GPU-heavy effects.Traffic and Terrain LOD unless MainThread time is also excessive.

If several timings are close, the limiter may alternate as the view and workload change. That usually indicates a reasonably balanced system, not a fault. Our broader MSFS 2024 performance checklist covers mixed GPU, VRAM and scenery-streaming constraints.

How do I fix MSFS 2024 when it is main thread limited?

If MSFS 2024 is limited by main thread for most of a representative flight, reduce the workloads that the CPU must simulate, coordinate and prepare. Change one variable at a time so that an aircraft, weather or traffic change does not invalidate the comparison.

  1. Lower Terrain Level of Detail first. Terrain LOD is usually the strongest CPU-side graphics control, particularly around large cities and detailed airports. Reduce it in moderate steps and watch the MainThread time.
  2. Reduce Objects Level of Detail. Objects LOD controls how far away many buildings, vegetation items and airport objects are prepared. Lower it when dense scenery causes the warning.
  3. Cut traffic and airport activity. Test with AI or live aircraft, multiplayer traffic, ground aircraft, airport workers and vehicles, road traffic and boats reduced or disabled. Add categories back separately to identify the expensive one.
  4. Separate the aircraft from the location. Fly a simpler default aircraft from the same airport. A large improvement implicates the original aircraft’s systems, avionics or cockpit displays. If there is little change, repeat the test at a less detailed airport.
  5. Test without third-party packages. Move the contents of the Community folder to a temporary location, disable other non-essential packages where practical and restart the simulator. Restore packages in batches, then test individual items from the affected batch. Do not delete packages during diagnosis.
  6. Remove background CPU competition. Close browser video, recording tools, traffic injectors, overlays and external cockpit or panel applications. Check for CPU thermal throttling and use an appropriate Windows power mode. Do not disable CPU cores or force processor affinity; those tweaks often make scheduling worse.
  7. Set a sustainable cap after tuning. Once the uncapped test is complete, cap the frame rate slightly below what the system can maintain in demanding locations. A cap does not remove the CPU bottleneck, but the extra headroom often improves frame pacing.

MainThread load often rises sharply on approach because the simulator adds airport objects, traffic, avionics activity and detailed scenery at the same time. If the problem is concentrated there, use our focused checks for FPS drops and stutters while landing.

Why does lowering resolution not fix a main thread limit?

Resolution and render scale mainly change the number of pixels processed by the GPU; they do not substantially reduce flight simulation, traffic, aircraft systems or scenery preparation on the MainThread. Lowering resolution can therefore shorten GPU time while leaving FPS unchanged and making the MainThread status appear even more clearly.

If the GPU has spare frame-time capacity, you may be able to increase selected GPU-heavy settings without reducing the native frame rate. Frame generation can make motion look smoother on supported hardware, but it does not accelerate the underlying simulation or repair CPU-driven stutters.

Why does the warning change between MainThread, graphics queue and GPU?

The active limiter changes with the workload. A glass cockpit at a busy airport may be MainThread-limited, external views with heavy clouds may become GPU-limited, and scenery or resource transitions can briefly expose the graphics queue.

Do not chase every momentary label change. Tune for the sustained limit in the hardest representative situation you regularly fly, then verify that all stages stay close to your chosen frame-time budget. V-Sync and frame caps can also introduce deliberate waiting, which is why they should be disabled during diagnosis and restored afterwards.

Do I need a faster CPU for a MainThread limit?

A CPU upgrade is justified only when MainThread time remains above your target after lowering Terrain and Objects LOD, reducing traffic, testing a simple aircraft, removing third-party content and closing background applications. Strong per-core gaming performance and suitable memory performance matter more to this workload than a large core count alone.

Even powerful processors can become main thread limited in detailed airliners at major airports. The practical target is stable frame pacing at an acceptable visual quality, not forcing the diagnostic label to disappear everywhere.

AI Assistant New

Still stuck? Ask Fly Away

Ask Fly Away is our AI flight-sim assistant. Ask your exact question and get a direct, step-by-step answer in seconds — free to try.

Ask Fly Away Free preview · unlimited for PRO members