The Professional Troubleshooting Process

Estimated Lesson Time: 35–45 Minutes

Lesson Overview

Throughout the previous modules, you have learned how Microsoft Flight Simulator uses your hardware, how to configure Windows and graphics drivers, how to manage add-ons and how to benchmark performance accurately.

You now have the knowledge required to optimise the simulator.

The next stage is learning how to troubleshoot it.

When Microsoft Flight Simulator develops a problem, many users immediately begin trying random fixes:

• Changing graphics settings.
• Clearing every cache.
• Reinstalling drivers.
• Removing add-ons.
• Editing Windows settings.
• Reinstalling the entire simulator.

Occasionally, one of these actions appears to solve the issue. However, because no structured investigation took place, the user often does not know:

• What caused the problem.
• Which action solved it.
• Whether the problem is genuinely fixed.
• Whether another unnecessary change created a new issue.

Professional troubleshooting works differently.

Instead of guessing, we follow a controlled process:

1. Define the problem clearly.
2. Reproduce it consistently.
3. Gather evidence.
4. Identify the most likely category.
5. Eliminate variables.
6. Test one change at a time.
7. Confirm the result.
8. Record the solution.

This lesson introduces the troubleshooting method that will be used throughout Module 7.

Lesson Objectives

By the end of this lesson, you will understand:

Why random troubleshooting wastes time.

How to define a technical problem accurately.

How to reproduce an issue consistently.

How to create a structured troubleshooting workflow.

How to use your Performance Profile as evidence.

How to eliminate possible causes.

Why only one variable should be changed at a time.

How benchmark flights can help diagnose problems.

How to confirm that a problem has genuinely been solved.

1. Troubleshooting Is a Process of Elimination

Troubleshooting is not about knowing every possible fix from memory.

It is about progressively narrowing down the list of possible causes.

Imagine that your simulator begins stuttering during approach.

Possible causes might include:

• The destination airport.
• AI traffic loading.
• A scenery add-on.
• Photogrammetry streaming.
• VRAM pressure.
• MainThread load.
• A background application.
• Shader compilation.
• Rolling Cache behaviour.
• A recently installed simulator update.

Trying to fix all of these at once would create confusion.

Instead, professional troubleshooting asks:

Which category is most likely responsible, and what test can prove or disprove it?

Every test should eliminate at least one possible cause.

2. Why Guessing Wastes Time

Random troubleshooting usually follows this pattern:

1. A problem appears.
2. The user searches online.
3. Ten unrelated fixes are suggested.
4. The user applies all ten.
5. The problem changes or temporarily disappears.
6. Nobody knows which action mattered.

This creates several problems.

You lose the original configuration

After changing multiple Windows, driver and simulator settings, returning to the original setup becomes difficult.

You cannot identify the successful fix

Even if the problem disappears, you do not know which change solved it.

You may introduce new problems

An unrelated optimisation can create:

• Reduced image quality.
• New stutters.
• Driver conflicts.
• Instability.
• Incorrect power behaviour.

You cannot repeat the solution

If the problem returns after a future update, you have no reliable process to follow.

Professional troubleshooting replaces random action with controlled evidence.

3. Start by Defining the Symptom

Before attempting a fix, describe exactly what is happening.

Avoid vague statements such as:

“My simulator runs badly.”

Instead, define the symptom precisely.

For example:

“The simulator drops from approximately 60 FPS to 35 FPS during the final five miles of approach into a third-party Heathrow scenery while using the Fenix A320 and FSLTL.”

That description already provides useful information.

It tells us:

• The issue is performance-related.
• It appears during approach.
• It occurs near a specific airport.
• A complex aircraft is being used.
• AI traffic is active.
• The drop appears location-dependent.

A precise symptom gives your investigation direction.

4. Questions to Ask Before Troubleshooting

Begin every investigation by answering the following questions.

What exactly is happening?

Examples:

• Low FPS.
• Micro-stutters.
• Major pauses.
• Long loading time.
• Crash to desktop.
• Black screen.
• Missing scenery.
• Texture pop-in.

When does it happen?

Examples:

• At simulator startup.
• At one specific airport.
• During taxi.
• During take-off.
• During cruise.
• On approach.
• After landing.
• After several hours of flying.

Does it happen every time?

A repeatable issue is much easier to diagnose than an intermittent one.

What changed recently?

Examples:

• Simulator update.
• Graphics driver update.
• New airport.
• New aircraft.
• New utility.
• Windows update.
• BIOS change.
• New hardware.

Is the issue local or global?

Does it happen:

• At one airport?
• With one aircraft?
• In every flight?
• Only in VR?
• Only with one add-on active?

These questions help determine the correct troubleshooting category. 

5. Build a Timeline

The timing of the problem is often one of the strongest clues.

Ask:

When was the simulator last working normally?

Then list everything that changed between the last known good session and the first problematic session.

Example:

Last known good configuration

• Stable graphics driver.
• Previous simulator version.
• Default Heathrow.
• No FSLTL.
• Stable benchmark result.

Changes made

• New graphics driver installed.
• Third-party Heathrow added.
• FSLTL activated.
• Sim Update installed.

You now have four clear variables to investigate.

Without this timeline, users often troubleshoot components that were never related to the problem.

6. Reproducing the Problem Consistently

A problem must be repeatable before it can be measured properly.

Suppose a stutter occurs once during a two-hour flight.

That could be caused by:

• Scenery streaming.
• A background Windows task.
• Shader compilation.
• A temporary network issue.

One isolated stutter is difficult to diagnose.

However, if the simulator stutters every time you pass the same point on approach, you have a repeatable test condition.

A Reproducible Test Should Include

• The same airport.
• The same aircraft.
• The same weather.
• The same time of day.
• The same route.
• The same camera view.
• The same traffic configuration.
• The same add-ons.

If the problem happens under those conditions every time, you can begin controlled testing.

7. Classifying the Problem

Before changing anything, place the issue into a general category.

Performance problem

Examples:

• Low FPS.
• Poor 1% lows.
• MainThread limitation.
• GPU limitation.

Stuttering problem

Examples:

• Frame-time spikes.
• Scenery loading pauses.
• Shader compilation hitches.
• VRAM-related stutters.

Loading problem

Examples:

• Slow simulator startup.
• Long flight loading.
• Content Manager delays.
• Scenery taking too long to appear.

Stability problem

Examples:

• Crash to desktop.
• Driver timeout.
• Black screen.
• Simulator freeze.

Visual problem

Examples:

• Flickering.
• Missing textures.
• Duplicate scenery.
• Terrain spikes.
• Broken lighting.

Correct classification prevents you from applying performance fixes to a stability issue or graphics-driver fixes to a scenery conflict.

8. Use the Performance Profile

Your Performance Profile is one of the most valuable troubleshooting tools you have created.

It contains your previous:

• Hardware specifications.
• Graphics settings.
• Driver version.
• Windows version.
• Simulator version.
• FPS results.
• 1% lows.
• MainThread status.
• GPU utilisation.
• VRAM usage.
• Temperatures.

When a problem appears, compare the current system with the last known good profile.

Example

Previous benchmark

• Average FPS: 72
• 1% low: 61
• GPU utilisation: 97%
• VRAM usage: 11 GB
• MainThread: occasional limitation
• GPU temperature: 66°C

Current benchmark

• Average FPS: 54
• 1% low: 29
• GPU utilisation: 68%
• VRAM usage: 11.5 GB
• MainThread: continuously limited
• GPU temperature: 64°C

The evidence suggests that the GPU is no longer the main limitation.

The simulator has become more heavily MainThread limited.

That directs the investigation towards areas such as:

• AI traffic.
• Aircraft systems.
• Airport objects.
• Ground vehicles.
• Glass cockpit refresh.
• CPU background activity.

The Performance Profile turns a vague complaint into a measurable diagnosis.

9. Establish a Known-Good Baseline

A known-good baseline is a configuration that previously worked correctly.

It may include:

• A stable driver.
• A clean Community Folder.
• A saved graphics profile.
• A known simulator version.
• A repeatable benchmark flight.

Before testing advanced fixes, return as close as possible to this stable configuration.

This gives you a reliable reference point.

10. Eliminate Variables

Eliminating variables means temporarily simplifying the simulator until the problem disappears.

You then reintroduce each element gradually.

For example, if the simulator crashes at one airport:

Test 1

Load the same airport with the Community Folder disabled.

Test 2

Load the same airport with only the scenery enabled.

Test 3

Enable the aircraft add-on.

Test 4

Enable GSX.

Test 5

Enable FSLTL.

If the crash returns after enabling FSLTL, you have identified a likely relationship that requires further testing.

This is much more reliable than uninstalling the simulator immediately.

11. Begin With the Least Invasive Tests

A professional troubleshooting workflow starts with simple, reversible actions.

Low-risk checks

• Restart the simulator.
• Restart the PC.
• Confirm the correct graphics profile is active.
• Check whether downloads or updates are running.
• Test a default aircraft.
• Test a default airport.
• Temporarily disable recent add-ons.

Higher-impact actions

• Reinstall graphics drivers.
• Use DDU.
• Repair simulator files.
• Reset configuration files.
• Reinstall the simulator.

Do not begin with the most destructive option.

A complete reinstall can take hours and may not solve a problem caused by one add-on.

12. Change One Variable at a Time

This is the most important troubleshooting rule.

Suppose you have:

• Disabled FSLTL.
• Reduced Terrain LOD.
• Changed the graphics driver.
• Cleared Rolling Cache.
• Disabled Frame Generation.

The performance problem disappears.

Which action solved it?

You do not know.

Instead, test changes individually.

Correct method

1. Record the original result.
2. Disable FSLTL.
3. Repeat the benchmark.
4. Record the result.
5. Restore FSLTL if it was not responsible.
6. Test the next variable.

This process may appear slower at first, but it prevents hours of confusion later.

13. Temporary Improvement Is Not Proof

A problem disappearing once does not automatically confirm a fix.

Performance naturally varies slightly between flights.

Background activity, streaming and shader compilation can influence individual results.

A genuine fix should:

• Improve repeated benchmark runs.
• Remove or reduce the original symptom.
• Remain stable after restarting the simulator.
• Avoid creating new issues.

Always repeat the test at least twice when practical.

For small performance changes, three benchmark runs can help determine whether the improvement is repeatable or simply normal variation.

14. Use Benchmark Flights for Diagnosis

Your permanent benchmark flight was not created only for measuring FPS.

It can also help determine whether a problem is:

• Global.
• Location-specific.
• Aircraft-specific.
• Weather-specific.
• Add-on-specific.
• Driver-related.

Example 1: Normal benchmark, poor normal flight

If your permanent benchmark performs normally but another airport performs badly, the problem is likely connected to:

• That airport.
• Nearby photogrammetry.
• Add-ons used during that flight.
• Traffic density.
• The chosen aircraft.

Example 2: Benchmark also performs badly

If the permanent benchmark now performs worse than its historical results, the cause is more likely to be:

• Driver change.
• Simulator update.
• Windows change.
• Global graphics configuration.
• Hardware issue.
• Background software.

This distinction can significantly reduce troubleshooting time.

15. Read the Evidence Correctly

Different measurements point towards different causes.

High GPU utilisation with poor FPS

Likely GPU limitation.

Review:

• Resolution.
• Render scaling.
• Clouds.
• Shadows.
• Reflections.
• Anti-aliasing.

Low GPU utilisation with MainThread limitation

Likely CPU-side limitation.

Review:

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

High VRAM usage with stutters

Possible VRAM pressure.

Review:

• Texture resolution.
• Airport textures.
• Render resolution.
• Static aircraft.
• Multiple high-detail add-ons.

Falling clock speeds with rising temperatures

Possible thermal throttling.

Review:

• Cooling.
• Dust.
• Fan behaviour.
• Case airflow.
• Power settings.

Problem occurs only with one add-on

Likely add-on conflict, incompatibility or poor configuration.

The data should guide the next test.

16. Record Every Change

Create a troubleshooting log.

For every test, record:

• Date.
• Problem.
• Test condition.
• Change made.
• Result.
• Whether the change was kept or reversed.