Advanced Troubleshooting Scenarios

Estimated Lesson Time: 60–70 Minutes

Lesson Overview

Welcome to Lesson 8 of Module 7.

Throughout this module, you have learned how to diagnose:

• Low FPS.
• Stuttering.
• Long loading times.
• Crashes to desktop.
• Performance changes after simulator updates.
• Hardware-related instability.

You have also learned the most important rule of professional troubleshooting:

Do not begin with a fix. Begin with evidence.

In this lesson, you will apply that process to five realistic Microsoft Flight Simulator problems.

Each scenario has been designed to test a different area of your knowledge. Some problems are primarily CPU-related, others involve the GPU, graphics drivers, aircraft add-ons or Virtual Reality.

The objective is not simply to suggest a list of possible fixes.

For each scenario, you must:

1. Define the symptom.
2. Identify the important clues.
3. Form an initial hypothesis.
4. Select the safest and most useful tests.
5. Change one variable at a time.
6. Compare the results.
7. Confirm the cause.
8. Document the final solution.

By the end of this lesson, you should be able to approach unfamiliar simulator problems confidently without relying on random online advice.

Lesson Objectives

By the end of this lesson, you will be able to:

Analyse realistic simulator problems.

Separate symptoms from causes.

Identify the most relevant troubleshooting category.

Build a logical test order.

Use benchmark and monitoring data correctly.

Distinguish CPU, GPU, VRAM, add-on and driver problems.

Explain the reasoning behind every troubleshooting step.

Avoid unnecessary reinstalls and destructive changes.

Confirm whether a proposed fix genuinely worked.

The Scenario Diagnosis Framework

Use the following framework for every scenario in this lesson.

Stage 1 – Define the Problem

Record:

• What is happening?
• When does it happen?
• Where does it happen?
• Is it repeatable?
• What changed recently?

Stage 2 – Identify the Category

Decide whether the problem is mainly related to:

• Performance.
• Stuttering.
• Loading.
• Stability.
• Driver behaviour.
• Add-ons.
• Hardware.
• Virtual Reality.

Stage 3 – Gather Evidence

Record:

• Average FPS.
• 1% lows.
• Frame times.
• MainThread status.
• GPU utilisation.
• VRAM usage.
• RAM usage.
• CPU and GPU temperatures.
• Event Viewer or Reliability Monitor results where relevant.

Stage 4 – Form a Hypothesis

State the most likely cause and explain why.

Stage 5 – Test One Variable

Choose the most useful, least invasive test.

Stage 6 – Compare

Repeat the exact same scenario and compare the result.

Stage 7 – Confirm

Repeat the successful test before declaring the issue solved.

Stage 8 – Document

Record the confirmed cause, the fix and the final configuration.

Scenario 1

“My FPS dropped after installing Heathrow.”

Reported Problem

A student installs a detailed third-party Heathrow scenery package.

Before installation, the simulator averaged approximately 70 FPS at Heathrow.

After installing the new scenery, performance falls to around 48 FPS.

The student immediately assumes that the scenery is badly optimised.

Step 1 – Define the Symptom

The first task is to make the report more precise.

Ask:

• Was the same aircraft used before and after?
• Was the same gate used?
• Was the weather identical?
• Was AI traffic identical?
• Was the default Heathrow completely removed or disabled?
• Are static aircraft enabled?
• Is nearby London photogrammetry active?
• Did the scenery installer add optional high-resolution textures or interiors?

A better problem description might be:

“Average FPS dropped from 70 to 48 while parked at the same gate using the same aircraft and weather immediately after installing a third-party Heathrow scenery.”

This confirms that the airport installation is strongly associated with the change.

Step 2 – Identify the Likely Performance Category

The airport may increase:

CPU workload

Through:

• Additional objects.
• Jetways.
• Ground vehicles.
• Airport workers.
• Static aircraft.
• More draw calls.
• Nearby scenery management.

GPU workload

Through:

• High-resolution textures.
• Terminal glass.
• Dynamic lighting.
• Shadows.
• Interior modelling.
• Reflections.

VRAM usage

Through:

• Larger texture packages.
• Detailed terminal assets.
• Static aircraft textures.
• Custom ground imagery.

The correct diagnosis depends on the measured bottleneck.

Step 3 – Gather Evidence

Record:

• Average FPS.
• 1% low.
• MainThread status.
• GPU utilisation.
• VRAM usage.
• RAM usage.
• CPU temperature.
• GPU temperature.

Example Result A

• Average FPS: 48.
• GPU utilisation: 65%.
• MainThread: heavily limited.
• VRAM: 10 GB of 16 GB.
• Temperatures: normal.

Interpretation

The GPU has available headroom.

The CPU MainThread is the main limitation.

Likely causes include:

• High airport object density.
• Static aircraft.
• Ground traffic.
• AI traffic.
• Airport workers.
• High Object LOD.
• Duplicate scenery.

Example Result B

• Average FPS: 48.
• GPU utilisation: 99%.
• MainThread: stable.
• VRAM: 15.5 GB of 16 GB.
• Temperatures: normal.

Interpretation

The GPU and VRAM are under heavy pressure.

Likely causes include:

• High-resolution airport textures.
• Detailed interiors.
• Reflections.
• Shadows.
• Static aircraft.
• High render resolution.

The two cases require different solutions.

Step 4 – Check for Duplicate Scenery

Before lowering graphics settings, verify that only one Heathrow package is active.

Possible duplication includes:

• Default handcrafted Heathrow.
• Marketplace Heathrow.
• Community-folder Heathrow.
• An older version left behind.
• Optional scenery from a World Update.
• Multiple add-on variants.

Why This Test Comes First

Duplicate scenery can create:

• Double objects.
• Extra jetways.
• Conflicting ground layouts.
• Increased CPU workload.
• Increased GPU workload.
• Visual corruption.

There is no value in optimising settings while two airport versions are active.

Step 5 – Test Optional Scenery Features

If the airport provides configuration options, test one change at a time.

Possible options include:

• Static aircraft off.
• Terminal interiors reduced or disabled.
• Lower texture package.
• Reduced clutter.
• Lower ground equipment density.
• Optional nearby landmarks disabled.

Repeat the same benchmark after each adjustment.

Step 6 – Adjust the Correct Settings

If MainThread Limited

Test:

• AI traffic.
• Ground aircraft.
• Airport workers.
• Ground vehicles.
• Object LOD.
• Terrain LOD.

If GPU Limited

Test:

• Texture Resolution.
• Shadows.
• Reflections.
• Clouds.
• Render Scaling.
• Airport-specific high-resolution texture options.

If VRAM Limited

Test:

• Texture Resolution.
• Render resolution.
• Static aircraft.
• Detailed interiors.
• Other nearby high-resolution scenery.

Likely Diagnosis

The airport is not automatically “poorly optimised.”

A more accurate conclusion may be:

“The third-party Heathrow adds substantially more airport objects and textures than the default version, creating a heavier MainThread and VRAM workload.”

The correct optimisation is to reduce the most expensive optional features while preserving the elements that provide the greatest visual benefit.

Final Recommended Solution

A balanced Heathrow profile might include:

• Only one airport version active.
• Static aircraft disabled.
• Airport workers reduced.
• AI traffic balanced.
• Object LOD slightly reduced.
• High rather than Ultra textures where VRAM is limited.
• Airport-specific configuration documented.

Scenario 1 Conclusion

The FPS drop is real, but the correct response is not to lower every graphics setting.

The diagnosis depends on whether the new airport increased:

• CPU workload.
• GPU workload.
• VRAM pressure.
• Or all three.

Scenario 2

“The simulator stutters only on approach.”

Reported Problem

The simulator performs smoothly during:

• Taxi.
• Take-off.
• Climb.
• Cruise.

During descent and approach, however, repeated stutters begin.

The student assumes that the graphics card is struggling to render the airport.

Step 1 – Define the Pattern

The location of the stutter is the most important clue.

Ask:

• Does it occur at every airport?
• Only at detailed third-party airports?
• At a specific distance from the destination?
• Does it happen when AI aircraft appear?
• Does it occur when switching cockpit views?
• Is Live Weather active?
• Is photogrammetry enabled?
• Does it happen only with complex aircraft?

The pattern suggests that new data is being loaded as the aircraft approaches the destination.

Step 2 – Identify Likely Causes

Approach stutters may be caused by:

• Destination airport loading.
• Photogrammetry streaming.
• AI traffic spawning.
• Ground vehicles activating.
• Airport objects loading.
• Glass cockpit workload.
• VRAM pressure.
• Scenery add-ons.
• Rolling Cache behaviour.
• Network instability.
• Shader compilation.

Step 3 – Record the Exact Stutter Location

Do not simply record “on approach.”

Record:

• Distance from airport.
• Altitude.
• Flight phase.
• Whether the destination has become visible.
• Whether AI traffic appeared.
• Whether the stutter repeats at the same point.

Example

“Stutters begin approximately 15 miles from Heathrow when descending below 5,000 feet and continue until landing.”

This strongly suggests destination scenery, traffic or airport object loading.

Step 4 – Gather Performance Data

Record during cruise and again during approach:

• Average FPS.
• 1% lows.
• Frame-time graph.
• MainThread status.
• GPU utilisation.
• VRAM usage.
• RAM usage.
• Network activity.
• Disk activity.

Example Result A

Cruise:

• GPU utilisation: 98%.
• MainThread: stable.
• VRAM: 9 GB.

Approach:

• GPU utilisation: 72%.
• MainThread: heavily limited.
• VRAM: 10 GB.

Interpretation

The problem shifts towards the CPU during approach.

Likely causes:

• AI traffic.
• Airport objects.
• Ground services.
• Complex aircraft calculations.
• Glass cockpit refresh.

Example Result B

Cruise:

• VRAM: 10 GB of 16 GB.
• GPU: 95%.

Approach:

• VRAM: 15.8 GB.
• GPU: 99%.
• Large frame-time spikes.

Interpretation

The destination scenery is creating VRAM and GPU pressure.

Example Result C

The stutter occurs only the first time approaching the airport after a driver update.

Interpretation

Shader compilation or fresh scenery caching may be contributing.

Step 5 – Isolate the Destination Airport

Test:

1. Same aircraft.
2. Same weather.
3. Same route.
4. Replace the third-party destination with the default airport.

If the stutters disappear, the airport or its surrounding scenery is involved.

If they remain, continue investigating traffic, aircraft and streaming.

Step 6 – Test AI Traffic

Disable or reduce traffic only.

Repeat the same approach.

If 1% lows improve and MainThread spikes reduce, traffic was a major contributor.

Step 7 – Test the Aircraft

Repeat the approach using a simpler aircraft.

If the problem improves significantly:

• Aircraft systems.
• Glass cockpit updates.
• EFB activity.
• Navigation processing.

may be contributing.

Step 8 – Test Streaming and Cache Behaviour

If the stutter appears while scenery loads:

• Compare photogrammetry on and off.
• Check network stability.
• Test Rolling Cache enabled and disabled.
• Monitor disk activity.
• Confirm the simulator is installed on fast storage.

Do not clear every cache immediately.

Use controlled comparisons.

Likely Diagnosis

A common final diagnosis might be:

“The stutters occur when the detailed destination airport, AI traffic and complex aircraft systems become active simultaneously, causing MainThread frame-time spikes.”

The long-term solution may require balancing several CPU-heavy features rather than changing one GPU setting.

Final Recommended Solution

Possible final profile:

• AI traffic reduced.
• Airport workers reduced.
• Object LOD adjusted.
• Glass Cockpit Refresh Rate lowered where appropriate.
• Duplicate scenery removed.
• Photogrammetry tested.
• Rolling Cache configuration chosen through benchmarking.

Scenario 2 Conclusion

Approach stutters usually reveal a workload transition.

The simulator moves from the relatively stable cruise phase into a demanding environment involving:

• New scenery.
• Airport traffic.
• Ground objects.
• Detailed aircraft systems.
• Weather and visibility changes.

The exact metrics determine which variable should be tested first.

Scenario 3

“Performance dropped after a graphics-driver update.”

Reported Problem

A student updates the NVIDIA or AMD graphics driver.

Before the update:

• Simulator performance was smooth.
• Average FPS was stable.
• No graphical issues were present.

After the update:

• Average FPS is lower.
• New stutters appear.
• Frame Generation may behave differently.
• The student wants to use DDU immediately.

Step 1 – Establish the Timeline

Confirm:

• Previous driver version.
• New driver version.
• Whether the driver installation was standard or clean.
• Whether the simulator was updated at the same time.
• Whether graphics settings changed.
• Whether shader caches are rebuilding.
• Whether the driver profile was reset.

Step 2 – Check Driver Profile Settings

Driver updates can sometimes affect:

• NVIDIA Control Panel profiles.
• AMD Adrenalin profiles.
• Power Management Mode.
• G-SYNC or FreeSync settings.
• V-Sync.
• Frame-rate caps.
• Texture Filtering.
• Preferred refresh rate.
• Overlay settings.

Also verify in-game settings such as:

• DLSS or FSR.
• Frame Generation.
• V-Sync.
• Resolution.
• Render Scaling.

Step 3 – Allow Shader Rebuilding

After a driver update, the shader cache may rebuild.

Possible temporary symptoms include:

• Camera-movement stutters.
• Hitches at new airports.
• Small pauses around clouds and lighting.
• Worse first-run 1% lows.

Run the permanent benchmark more than once before deciding that the driver is worse.

Step 4 – Compare Performance Properly

Use identical:

• Airport.
• Aircraft.
• Weather.
• Graphics settings.
• Driver profile.
• Add-ons.
• Traffic settings.

Record:

• Average FPS.
• 1% lows.
• Frame times.
• GPU utilisation.
• GPU clock speed.
• Power draw.
• VRAM usage.
• Temperatures.

Example Result A

First run after update:

• Average FPS: 60.
• 1% low: 30.

Third run:

• Average FPS: 69.
• 1% low: 56.

Interpretation

Shader rebuilding was likely responsible for the temporary stutters.

Example Result B

All repeated runs show:

• Lower average FPS.
• Lower GPU clocks.
• Lower power draw.
• No temperature problem.

Interpretation

Power-management behaviour or the driver profile may have changed.

Example Result C

• Black-screen flickering.
• Driver timeout.
• Crashes in multiple games.

Interpretation

This is more likely to be a genuine driver or stability problem.

Step 5 – Decide Whether Rollback Is Appropriate

Rollback is reasonable when:

• The previous driver was stable.
• The issue began immediately after the update.
• Repeated benchmarks confirm the regression.
• The problem persists after shader rebuilding.
• Driver settings have been verified.
• Other GPU-intensive applications show similar issues.

Step 6 – Decide Whether DDU Is Appropriate

DDU should be reserved for cases such as:

• Corrupted installation.
• Standard reinstall failed.
• Persistent driver crashes.
• Switching GPU manufacturers.
• Driver components remain broken.

Do not use DDU simply because the first benchmark after an update contains stutters.

Likely Diagnosis

The correct diagnosis may be one of several outcomes:

Temporary shader rebuilding

No rollback required.

Driver profile reset

Restore the correct settings.

Genuine regression

Rollback to the known stable driver.

Corrupted installation

Perform a clean install, then consider DDU only if necessary.

Final Recommended Solution

A professional response might be:

1. Verify all settings.
2. Complete repeated benchmark runs.
3. Confirm whether shaders are still rebuilding.
4. Check GPU clocks and power behaviour.
5. Compare with the previous driver.
6. Roll back only if the regression is repeatable.
7. Use DDU only when ordinary driver repair fails.

Scenario 3 Conclusion

A graphics-driver update is strongly associated with the problem, but association is not proof.

The student must separate:

• Temporary shader behaviour.
• Reset settings.
• Driver regression.
• Corrupted installation.
• Unrelated simulator changes.

Scenario 4

“The simulator crashes every time I load the PMDG.”

Reported Problem

The simulator starts normally.

The main menu works.

Default aircraft load successfully.

Every attempt to load the PMDG results in a crash to desktop.

Step 1 – Define the Scope

Important clues:

• The problem appears aircraft-specific.
• Default aircraft work.
• The simulator itself launches normally.
• The crash is repeatable.

This makes a global hardware failure less likely as the first hypothesis.

Step 2 – Ask What Changed

Possible recent changes include:

• PMDG update.
• Simulator update.
• New livery.
• New aircraft configuration.
• Navigation database update.
• GSX profile.
• Panel-state file.
• Driver update.
• Marketplace or Community duplication.

Step 3 – Test a Different Airport

Load the PMDG at:

• A simple default airport.
• Clear weather.
• No traffic.
• No external utilities.

If it loads, the aircraft itself is probably not completely broken.

The crash may involve:

• The original airport.
• GSX.
• Traffic.
• Scenery.
• Combined memory pressure.

Step 4 – Remove Aircraft-Specific Variables

Test without:

• Custom liveries.
• Custom panel states.
• GSX aircraft profiles.
• External EFB integrations.
• Additional aircraft utilities.

Use the default PMDG configuration.

Step 5 – Check Add-on Compatibility

Verify that the PMDG version is compatible with the current simulator build.

Also review:

• Navigation-data version.
• Required support libraries.
• Aircraft installer updates.
• Known compatibility issues.

Step 6 – Test the Community Folder

If the aircraft is installed in or interacts with Community content:

1. Disable unrelated packages.
2. Keep only the PMDG and required dependencies active.
3. Test the aircraft at a default airport.
4. Re-enable utilities one at a time.

Step 7 – Review Reliability Monitor and Event Viewer

Record:

• Crash time.
• Faulting application.
• Faulting module.
• Exception code.
• Any driver or memory errors.

Remember that the listed module is evidence, not necessarily the root cause.

Step 8 – Monitor Memory

Complex aircraft may expose:

• RAM instability.
• VRAM pressure.
• Page-file problems.
• Corrupted aircraft files.

Record:

• RAM usage.
• VRAM usage.
• Storage free space.
• Page-file status.
• Temperatures.

If the crash occurs during aircraft loading at every location, corrupted package files become more likely.

Step 9 – Repair or Reinstall the Aircraft First

Before reinstalling the entire simulator:

• Verify the aircraft installation.
• Remove old aircraft files correctly.
• Reinstall the current PMDG package.
• Reinstall liveries separately.
• Test the clean aircraft before restoring extras.

This is far more targeted than reinstalling MSFS.

Possible Final Diagnoses

Outdated PMDG version

Update the aircraft.

Corrupted aircraft package

Clean reinstall the aircraft.

Broken livery

Remove the affected livery.

GSX or utility conflict

Update or rebuild the related profile.

Airport and aircraft combination

Optimise or remove the conflicting scenery.

System-wide memory instability

Investigate RAM only if other applications or aircraft also crash.

Scenario 4 Conclusion

Because the crash is isolated to one aircraft, the first investigation should focus on:

• Aircraft compatibility.
• Aircraft files.
• Aircraft-specific utilities.
• Liveries.
• The chosen airport.

Global fixes should come later only if the evidence expands beyond the PMDG.

Scenario 5

“VR performance suddenly became terrible.”

Reported Problem

A student previously had a stable VR experience.

Now they report:

• Severe judder.
• Blurry image.
• Poor frame timing.
• Motion reprojection behaving incorrectly.
• Lower performance.

The student has not knowingly changed the simulator graphics settings.

Step 1 – Identify What Changed Outside MSFS

VR performance is influenced by several layers:

• Headset software.
• OpenXR runtime.
• SteamVR.
• Meta Quest software.
• Windows Mixed Reality where applicable.
• Graphics driver.
• Headset refresh rate.
• Render resolution.
• Link quality.
• Motion-reprojection settings.

The simulator may be unchanged while the VR runtime has changed.

Step 2 – Record the Current VR Configuration

Record:

• Headset model.
• Active runtime.
• Refresh rate.
• Render resolution.
• SteamVR scaling.
• OpenXR scaling.
• In-game render scaling.
• DLSS or TAA mode.
• Motion reprojection.
• Foveated rendering.
• Graphics-driver version.

Multiple scaling settings may accidentally multiply the total render resolution.

Step 3 – Check for Double Scaling

Example:

• Headset software resolution: 120%.
• SteamVR resolution: 150%.
• In-game render scaling: 120%.

The combined workload may be far higher than expected.

Restore one clear scaling strategy and avoid stacking unnecessary resolution increases.

Step 4 – Check Refresh Rate

A headset may have changed from:

• 72 Hz to 90 Hz.
• 80 Hz to 120 Hz.

Higher refresh rates create a much larger GPU workload.

If the system cannot meet the new target, frame timing can deteriorate severely.

Step 5 – Check Motion Reprojection

Verify whether it is:

• Enabled.
• Disabled.
• Forced.
• Operating at the expected ratio.
• Producing artefacts.

A change in runtime or driver behaviour may affect reprojection even if MSFS settings remain unchanged.

Step 6 – Monitor the Correct Metrics

Record:

• GPU utilisation.
• VRAM usage.
• CPU frame time.
• GPU frame time.
• Reprojection status.
• Headset frame rate.
• Temperatures.
• Clock speeds.

Example Result A

GPU frame time is too high while CPU frame time remains stable.

Interpretation

GPU or resolution workload is the main problem.

Test:

• Render resolution.
• DLSS mode.
• Clouds.
• Shadows.
• Reflections.

Example Result B

CPU frame time is too high at airports while GPU has headroom.

Interpretation

MainThread workload is the problem.

Test:

• AI traffic.
• Terrain LOD.
• Object LOD.
• Glass cockpit refresh.
• Airport workers.

Example Result C

VRAM is near capacity and stutters appear during head movement.

Interpretation

Reduce:

• Texture Resolution.
• Render scaling.
• Airport detail.
• Other high-resolution add-ons.

Step 7 – Check Runtime and Driver Changes

If the issue began after:

• Graphics-driver update.
• OpenXR update.
• SteamVR update.
• Headset firmware update.

test the relevant component before changing the entire simulator configuration.

Step 8 – Create a Clean VR Test

Use:

• Default aircraft.
• Default airport.
• Clear weather.
• No AI traffic.
• Conservative VR profile.

If performance is still poor, the issue is likely in:

• Runtime.
• Driver.
• Headset software.
• Hardware.
• USB or link connection.

If performance is good, reintroduce demanding simulator features one at a time.

Step 9 – Consider Connection Problems

For streaming or linked headsets, poor performance may also involve:

• USB bandwidth.
• Wireless congestion.
• Link cable.
• Network quality.
• Encoding bitrate.
• Background wireless traffic.

This can feel like rendering stutter even when GPU performance appears acceptable.

Likely Diagnoses

Refresh rate increased

Restore a sustainable rate.

Render scaling changed

Return to the previous profile.

Runtime changed

Select the correct OpenXR runtime.

Driver regression

Benchmark, then roll back if confirmed.

Motion reprojection disabled

Restore and retest.

VRAM pressure

Reduce resolution or texture load.

CPU bottleneck at airports

Reduce CPU-heavy simulator settings.

Scenario 5 Conclusion

VR troubleshooting must consider the entire software and hardware chain.

The simulator is only one layer.

A professional VR diagnosis checks:

• Runtime.
• Scaling.
• Refresh rate.
• Frame timing.
• Reprojection.
• Driver.
• Connection quality.
• Simulator workload.