couatl64_MSFS2024.exe randomly crashing in the background

[PilotGW]

Hi,

I've recently moved over to MSFS 2024 and installed GSX a few days ago.

I've noticed that if I fly around, even without touching GSX, that couatl64_MSFS2024.exe will randomly crash in the background. Sometimes back to back. It's happened 6 times today alone. I should note, it seems happen exclusively in flight and with different aircraft.

Code: [Select]

Description
Faulting Application Path: E:\Microsoft Flight Simulator Common\Addons\Utilities\Addon Manager\couatl64\couatl64_MSFS2024.exe

Problem signature
Problem Event Name: APPCRASH
Application Name: couatl64_MSFS2024.exe
Application Version: 5.0.0.6020
Application Timestamp: 68a72d4d
Fault Module Name: clr.dll
Fault Module Version: 4.8.9310.0
Fault Module Timestamp: 67db4f32
Exception Code: c0000005
Exception Offset: 000000000000657c
OS Version: 10.0.26100.2.0.0.256.48
Locale ID: 2057
Additional Information 1: 57d1
Additional Information 2: 57d1b217b3631ca7a6013087c8f7eca7
Additional Information 3: df18
Additional Information 4: df18a00a2396636b4c3ff128fb281f5c

Extra information about the problem
Bucket ID: 470a3265ef95919342302c2643910d50 (1310596034418773328)
It always cites clr.dll as the faulting module. At the same time a .NET Runtime error is listed in Event Viewer

Code: [Select]

Application: couatl64_MSFS2024.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FFB52F3657C (00007FFB52F30000) with exit code 80131506.
I've tried turning on logging within GSX, but the Couatl.log seems to start fresh every time Couatl reloads, so there are no clues there. It never leaves a panic log either (Couatl.ERR), so I'm flying blind.

I've tried:

• DISM and SFC. Some unrelated repairs made, but no change.
• Deactivating GSX, uninstalling it and FSDT Universal Installer and then reinstalling and reactivating everything.

The sim itself still runs and doesn't crash, but I've noticed stuttering coinciding with Couatl crashing and recovering.

I have:

9800X3D
64GB 6000MT/s RAM
RTX 5080
Windows 11 Pro

[PilotGW]

I've had a little more time to do some further testing. My steps to reproduce the issue are:

• Fenix A320 / Default A321 NEO.
• Takeoff EGLL 09L. Turn north, climbing 6000ft.

Couatl crashes within a few minutes of me getting airborne, regardless of me opening GSX or not.

I tried each of the following individually, restarting the simulator and/or PC each step:

• I reset my BIOS, effectively disabling EXPO, ruling out memory overclock instability. Still crashes.
  
  
• I disabled my CPU's integrated graphics. Still crashes.
  
  
• I uninstalled Navigraph navdata. Still crashes.
  
  
• I removed everything from my Community folder except GSX. Still crashes.
  
  
• I removed all downloaded GSX airport profiles from Appdata. Still crashes.
  
  
• I unticked .NET 3.5 and 4.8 in Windows Features, restarted and reticked them to force an update. Still crashes.
  
  
• I disabled Windows Defender firewall. Still crashes.
  
  
• I made sure Addon Manager is added as an exclusion in Windows Defender. It is. Still crashes.
  
  
• I disabled Steam Overlay. Still crashes.
  
  
• I re-ran DISM scan and SFC. No corruption. Still crashes.
  

So I'm at a loss. Any help would be appreciated.

[72westy]

I see this as well within Windows event viewer. My logs....

Log Name:      Application
Source:        Application Error
Date:          10/22/2025 11:20:20 PM
Event ID:      1000
Task Category: Application Crashing Events
Level:         Error
Keywords:     
User:          DESKTOP-AFGL0LD\usnao
Computer:      DESKTOP-AFGL0LD
Description:
Faulting application name: Couatl64_MSFS2024.exe, version: 5.0.0.6020, time stamp: 0x68a72d4d
Faulting module name: clr.dll, version: 4.8.9221.0, time stamp: 0x68531fc6
Exception code: 0xc0000005
Fault offset: 0x000000000000657c
Faulting process id: 0x501C
Faulting application start time: 0x1DC43E18059DBD6
Faulting application path: C:\Program Files (x86)\Addon Manager\couatl64\Couatl64_MSFS2024.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: a973b5f6-6eda-406d-8b1a-5c7abcf037c8
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" />
    <EventID>1000</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>100</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2025-10-23T06:20:20.3724895Z" />
    <EventRecordID>76159</EventRecordID>
    <Correlation />
    <Execution ProcessID="10416" ThreadID="24680" />
    <Channel>Application</Channel>
    <Computer>DESKTOP-AFGL0LD</Computer>
    <Security UserID="S-1-5-21-2400603791-3703659137-366786281-1002" />
  </System>
  <EventData>
    <Data Name="AppName">Couatl64_MSFS2024.exe</Data>
    <Data Name="AppVersion">5.0.0.6020</Data>
    <Data Name="AppTimeStamp">68a72d4d</Data>
    <Data Name="ModuleName">clr.dll</Data>
    <Data Name="ModuleVersion">4.8.9221.0</Data>
    <Data Name="ModuleTimeStamp">68531fc6</Data>
    <Data Name="ExceptionCode">c0000005</Data>
    <Data Name="FaultingOffset">000000000000657c</Data>
    <Data Name="ProcessId">0x501c</Data>
    <Data Name="ProcessCreationTime">0x1dc43e18059dbd6</Data>
    <Data Name="AppPath">C:\Program Files (x86)\Addon Manager\couatl64\Couatl64_MSFS2024.exe</Data>
    <Data Name="ModulePath">C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll</Data>
    <Data Name="IntegratorReportId">a973b5f6-6eda-406d-8b1a-5c7abcf037c8</Data>
    <Data Name="PackageFullName">
    </Data>
    <Data Name="PackageRelativeAppId">
    </Data>
  </EventData>
</Event>

[72westy]

2nd one...

Log Name:      Application
Source:        .NET Runtime
Date:          10/22/2025 11:20:20 PM
Event ID:      1023
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DESKTOP-AFGL0LD
Description:
Application: Couatl64_MSFS2024.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FF94169657C (00007FF941690000) with exit code 80131506.

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name=".NET Runtime" />
    <EventID Qualifiers="0">1023</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2025-10-23T06:20:20.0697911Z" />
    <EventRecordID>76158</EventRecordID>
    <Correlation />
    <Execution ProcessID="20508" ThreadID="0" />
    <Channel>Application</Channel>
    <Computer>DESKTOP-AFGL0LD</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Application: Couatl64_MSFS2024.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FF94169657C (00007FF941690000) with exit code 80131506.
</Data>
  </EventData>
</Event>

[72westy]

I also ran the following commands (w/admin rights) and when all completed successfully and without error/s. In the following order:

Dism.exe /online /Cleanup-Image /checkhealth

Dism.exe /online /Cleanup-Image /scanhealth

Dism.exe /online /Cleanup-Image /Restorehealth

sfc /scannow

Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

Dism.exe /Online /Cleanup-Image /StartComponentCleanup

RESTARTED computer as the last step.


My thought is the sim 2024 is crashing it. I'll report this on the MSFS 2020/2024 official forum as well so they are aware. Reported here: https://forums.flightsimulator.com/t/couatl64-msfs2024-exe-issue/743940

[virtuali]

The error seems to indicate a problem with .NET, which is quite strange, since the Couatl64 .exe is NOT a .NET app, it's a native x64 app that doesn't do any call to the .NET framework. So, I wonder if this might be something else entirely, like another app (antivirus, maybe) that DOES use .NET and attaches to the Couatl64.exe, which is what antivirus usually do to check.

[72westy]

Sorry for the late response. I use Avast free edition and I have exception within it for... c:\Program Files (x86) Addon Manager\*

Also found these in event viewer...

Log Name:      Application
Source:        Application Error
Date:          11/4/2025 7:07:17 PM
Event ID:      1000
Task Category: Application Crashing Events
Level:         Error
Keywords:     
User:          DESKTOP-AFGL0LD\usnao
Computer:      DESKTOP-AFGL0LD
Description:
Faulting application name: Couatl64_MSFS2024.exe, version: 5.0.0.6020, time stamp: 0x68a72d4d
Faulting module name: ucrtbase.dll, version: 10.0.26100.7019, time stamp: 0x55eee9bf
Exception code: 0xc0000409
Fault offset: 0x00000000000a4ace
Faulting process id: 0x2594
Faulting application start time: 0x1DC4DFE922FC8A8
Faulting application path: C:\Program Files (x86)\Addon Manager\couatl64\Couatl64_MSFS2024.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 3fdd62ea-fba5-4aea-84fd-cc970ca2341e
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" />
    <EventID>1000</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>100</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2025-11-05T03:07:17.6403883Z" />
    <EventRecordID>79914</EventRecordID>
    <Correlation />
    <Execution ProcessID="7880" ThreadID="22860" />
    <Channel>Application</Channel>
    <Computer>DESKTOP-AFGL0LD</Computer>
    <Security UserID="S-1-5-21-2400603791-3703659137-366786281-1002" />
  </System>
  <EventData>
    <Data Name="AppName">Couatl64_MSFS2024.exe</Data>
    <Data Name="AppVersion">5.0.0.6020</Data>
    <Data Name="AppTimeStamp">68a72d4d</Data>
    <Data Name="ModuleName">ucrtbase.dll</Data>
    <Data Name="ModuleVersion">10.0.26100.7019</Data>
    <Data Name="ModuleTimeStamp">55eee9bf</Data>
    <Data Name="ExceptionCode">c0000409</Data>
    <Data Name="FaultingOffset">00000000000a4ace</Data>
    <Data Name="ProcessId">0x2594</Data>
    <Data Name="ProcessCreationTime">0x1dc4dfe922fc8a8</Data>
    <Data Name="AppPath">C:\Program Files (x86)\Addon Manager\couatl64\Couatl64_MSFS2024.exe</Data>
    <Data Name="ModulePath">C:\WINDOWS\System32\ucrtbase.dll</Data>
    <Data Name="IntegratorReportId">3fdd62ea-fba5-4aea-84fd-cc970ca2341e</Data>
    <Data Name="PackageFullName">
    </Data>
    <Data Name="PackageRelativeAppId">
    </Data>
  </EventData>
</Event>

[72westy]

Log Name:      Application
Source:        Windows Error Reporting
Date:          11/4/2025 7:07:20 PM
Event ID:      1001
Task Category: None
Level:         Information
Keywords:     
User:          DESKTOP-AFGL0LD\usnao
Computer:      DESKTOP-AFGL0LD
Description:
Fault bucket 1399046419245935729, type 5
Event Name: BEX64
Response: Not available
Cab Id: 0

Problem signature:
P1: Couatl64_MSFS2024.exe
P2: 5.0.0.6020
P3: 68a72d4d
P4: ucrtbase.dll
P5: 10.0.26100.7019
P6: 55eee9bf
P7: 00000000000a4ace
P8: c0000409
P9: 0000000000000007
P10:

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.0c4f4571-80bc-4cb5-8837-6fea3401bbef.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.049f1ced-cbf1-4200-a769-a4267adad72d.tmp.WERInternalMetadata.xml
WPR_initiated_DiagTrackMiniLogger_OneTrace_User_Logger_20251101_1_EC_0_inject.etl
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.22c03db1-593a-4184-a30d-2761ecd1d691.tmp.etl
WPR_initiated_DiagTrackMiniLogger_WPR System Collector_inject.etl
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.ccd1acad-0d95-4f81-8ec7-f34ba0a1df95.tmp.etl
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.1ec01ea5-2bc6-491f-b57f-b626e4ae5c4d.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.bc711c2b-9ba7-4310-bd72-c37ae324c7ff.tmp.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.f845049c-d1a5-4bf7-8f67-756633bfc71a.tmp.xml

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Couatl64_MSFS202_8edc393eafdcf9a555c2499e7b4b2a6d5c2f1_617723cf_777cb840-f05b-4c88-802e-64d21f635bcb

Analysis symbol:
Rechecking for solution: 0
Report Id: 3fdd62ea-fba5-4aea-84fd-cc970ca2341e
Report Status: 268435456
Hashed bucket: 8b684033b82d1550136a694e4b6fac71
Cab Guid: 0
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Windows Error Reporting" Guid="{0ead09bd-2157-539a-8d6d-c87f95b64d70}" />
    <EventID>1001</EventID>
    <Version>0</Version>
    <Level>4</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2025-11-05T03:07:20.6923455Z" />
    <EventRecordID>79915</EventRecordID>
    <Correlation />
    <Execution ProcessID="7880" ThreadID="22860" />
    <Channel>Application</Channel>
    <Computer>DESKTOP-AFGL0LD</Computer>
    <Security UserID="S-1-5-21-2400603791-3703659137-366786281-1002" />
  </System>
  <EventData>
    <Data Name="Bucket">1399046419245935729</Data>
    <Data Name="BucketType">5</Data>
    <Data Name="EventName">BEX64</Data>
    <Data Name="Response">Not available</Data>
    <Data Name="CabId">0</Data>
    <Data Name="P1">Couatl64_MSFS2024.exe</Data>
    <Data Name="P2">5.0.0.6020</Data>
    <Data Name="P3">68a72d4d</Data>
    <Data Name="P4">ucrtbase.dll</Data>
    <Data Name="P5">10.0.26100.7019</Data>
    <Data Name="P6">55eee9bf</Data>
    <Data Name="P7">00000000000a4ace</Data>
    <Data Name="P8">c0000409</Data>
    <Data Name="P9">0000000000000007</Data>
    <Data Name="P10">
    </Data>
    <Data Name="AttachedFiles">
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.0c4f4571-80bc-4cb5-8837-6fea3401bbef.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.049f1ced-cbf1-4200-a769-a4267adad72d.tmp.WERInternalMetadata.xml
WPR_initiated_DiagTrackMiniLogger_OneTrace_User_Logger_20251101_1_EC_0_inject.etl
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.22c03db1-593a-4184-a30d-2761ecd1d691.tmp.etl
WPR_initiated_DiagTrackMiniLogger_WPR System Collector_inject.etl
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.ccd1acad-0d95-4f81-8ec7-f34ba0a1df95.tmp.etl
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.1ec01ea5-2bc6-491f-b57f-b626e4ae5c4d.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.bc711c2b-9ba7-4310-bd72-c37ae324c7ff.tmp.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.f845049c-d1a5-4bf7-8f67-756633bfc71a.tmp.xml</Data>
    <Data Name="StorePath">\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Couatl64_MSFS202_8edc393eafdcf9a555c2499e7b4b2a6d5c2f1_617723cf_777cb840-f05b-4c88-802e-64d21f635bcb</Data>
    <Data Name="AnalysisSymbol">
    </Data>
    <Data Name="Rechecking">0</Data>
    <Data Name="ReportId">3fdd62ea-fba5-4aea-84fd-cc970ca2341e</Data>
    <Data Name="ReportStatus">268435456</Data>
    <Data Name="HashedBucket">8b684033b82d1550136a694e4b6fac71</Data>
    <Data Name="CabGuid">0</Data>
  </EventData>
</Event>

[srcooke]

Seeing the same issue with the exact same details posted by the OP.

[thegreek]

Hi,

after several test flights and detailed Event Viewer / WER log reviews, I can confirm a consistent crash chain related to GSX (Couatl64_MSFS2024.exe) when running the MSFS 2024 SU4 Beta.
The issue occurs reproducibly during approach or shortly before touchdown.

Error pattern
Each sequence follows the same pattern:

Couatl64_MSFS2024.exe → ucrtbase.dll (0xc0000409)
Couatl64_MSFS2024.exe → clr.dll (0xc0000005)
[repeats several times]
FlightSimulator2024.exe → dxgi.dll (0xc0000005)

After the initial Couatl64 crash, the simulator continues for a while, then terminates with the usual DXGI Access Violation.

Technical observation
The statement that “Couatl64.exe is a native app not using .NET” does not fully explain the logs.
Windows Event Viewer clearly identifies clr.dll (Common Language Runtime) as the faulting module, which can only appear if a managed (.NET) component or runtime dependency is being loaded.

Couatl internally relies on Python and SimConnect, using Microsoft Visual C++ Runtimes and occasionally .NET-bound libraries through the bglmanx64 bridge.
The simultaneous faults in ucrtbase.dll (C Runtime) and clr.dll (.NET Runtime) strongly indicate a thread or memory-race condition inside the Couatl process itself, not an external injection.

If antivirus software were responsible, crash offsets and modules would vary between users.
However, multiple users (see https://forums.flightsimulator.com/t/couatl64-msfs2024-exe-issue/743940
) report the identical crash offset 0x657c in clr.dll, regardless of whether they use Defender, Avast, BitDefender, or no antivirus at all.
This consistency rules out external processes as the root cause.

Relation to SU4 Beta changes
MSFS 2024 SU4 introduced asynchronous SimConnect calls and new internal caching for Atmosphere / Airspeed SimVars (see changelog: “Fixed concurrent accesses …”).
It appears GSX may still perform synchronous or unsynchronized writes to these SimVars, which results in the .NET and C-Runtime exceptions in Couatl64 and ultimately leads to the DXGI crash in the simulator.

Suggested next steps
• Review Couatl’s SimConnect threading and exception-handling layer under SU4.
• Add diagnostic logging around SimVar writes or network threads.
• Reproduce with GSX active, no other add-ons, DX12 enabled, SU4 Beta.

This issue is reproducible and independent of antivirus software.
It would be very helpful if the dev team could investigate the Couatl64 → clr.dll crash path directly, as it consistently precedes every dxgi.dll CTD.

Best regards

[Daveo]

I get these crashes alot also around Germany EDHL EDDH area with 2024.
Have not flown around the U.K. much lately.

Have not seen anything NET related in Event Viewer.



Faulting application name: Couatl64_MSFS2024.exe, version: 5.0.0.6020, time stamp: 0x68a72d4d
Faulting module name: ucrtbase.dll, version: 10.0.19041.3636, time stamp: 0x81cf5d89
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process ID: 0x9a4
Faulting application start time: 0x01dc50b52553de9a
Faulting application path: E:\Addon Manager\couatl64\Couatl64_MSFS2024.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report ID: 5e667e53-aad0-4307-b825-b1ab0217609d
Faulting package full name:
Faulting package-relative application ID:

[thegreek]

Thanks for sharing your log.
That’s actually the same issue we’re all seeing, your crash just stops one step earlier in ucrtbase.dll, while in some cases it continues and triggers a second exception in clr.dll (.NET runtime) before the simulator eventually crashes with dxgi.dll.

Both originate from the same internal stack buffer overrun inside Couatl64, which explains why some users see only ucrtbase.dll and others see clr.dll as well.
So even if the .NET module isn’t directly part of GSX, it’s still affected once the process memory becomes corrupted after the initial overflow.

At least this is my assumption based on the crash data we’ve seen so far.

[Daveo]

It wouldn't be too bad if 2024 had a save function that worked where you could pick up off an autosave.
Why this does not exist I have no idea.

[virtuali]

The statement that “Couatl64.exe is a native app not using .NET” does not fully explain the logs.
Windows Event Viewer clearly identifies clr.dll (Common Language Runtime) as the faulting module, which can only appear if a managed (.NET) component or runtime dependency is being loaded.

The statement was correct: Couatl64.exe IS a native x64 app that doesn't make ANY .NET call, it's an unmanaged C++ app that doesn't use anything other than the win64 API. However, it's calling into the QLM/Soraco libraries using for licensing, and those libraries use .NET so, a generic problem with your .NET configuration might cause this.

The thing that leads to believe some external interference or a generic .NET problem, is that we NEVER check license "continuously". A license check for GSX or an airport is made only ONCE, when the program starts, and never again for the whole session so, the crash in the crl.dll happens later in the flight ?

Couatl internally relies on Python and SimConnect, using Microsoft Visual C++ Runtimes and occasionally .NET-bound libraries through the bglmanx64 bridge.

That's not the case. the bglmanx64.dll is NOT a "bridge" with the sim.

It doesn't run in it, and doesn't do anything in the sim, it's not connected with it through Simconnect and it's also not  .NET app either and it's not even linked or loads the QLM/Soraco libraries.

In MSFS, the couatl .exe loads the bglmanx64.dll ONLY to get a list of known products, so it won't have to replicate its code, so it works as just an utility to share code, and it has NO interaction whatsoever with the sim. This is completely different that what it used to be in FSX/P3D, where bglmanx64.dll is really running in the sim as a Simconnect app.

MSFS 2024 SU4 introduced asynchronous SimConnect calls and new internal caching for Atmosphere / Airspeed SimVars (see changelog: “Fixed concurrent accesses …”).
It appears GSX may still perform synchronous or unsynchronized writes to these SimVars, which results in the .NET and C-Runtime exceptions in Couatl64 and ultimately leads to the DXGI crash in the simulator.

GSX never tries to write to any of these variables. In general, GSX very rarely writes to ANY variables in the sim, the only time it does that, momentarily, is during Pushback, where it takes control of the airplane, but I don't think anybody ever reported a crash DURING Pushback, which is the only time GSX actually *writes* on some variables.

Most of the time, GSX sends EVENTS to the sim, which is the proper and safe way to change the status of the simulation without any risk. Events like TOGGLE JETWAY, for example.

This issue is reproducible and independent of antivirus software.It would be very helpful if the dev team could investigate the Couatl64 → clr.dll crash path directly, as it consistently precedes every dxgi.dll CTD.

It might be reproducible for you, but I run MSFS 2024 like 10 hours per day, and I never seen such crashes, not in the sim, not the the couatl engine. All reports I see indicate a crash after some time, which incidentally is the time where GSX DOES LESS.

In fact, if you are in cruise, it doesn't do ANYTHING, other check READING your position, speed and altitude, to know when its time to reactivate itself to check for nearby airports. And here's the ONLY thing that might be what I think it's the real cause of the crashes: the Navdata API.

- When you are on ground, GSX makes a single call to it, to load the airport you are in and get data about parking spots, taxiways, runway, jetways.

- When you are in flight, GSX calls into the Navdata PERIODICALLY, to know which airports are nearby., so you can open the menu and pre-select a gate for landing. These calls are done ONLY if you are below 10k feet and you have the "Disable in cruise" option disabled.

1) When you cross over 10k feet, GSX UNSUBSCRIBES to the Navdata. This means the sim should stop sending an updated list of nearby airports.

2) When you are again below 10k feet, GSX SUBSCRIBES again to the Navdata, so it would regularly get updated airports in the area while you flying.


It would be interesting to notice if those reproducible issues (which I can't reproduce), happened in case #1, only case #2 or both. Because, if you put together all facts:

- Nobody seems to report crashes when just parked on ground, and this is when GSX does the most stutt EXCEPT calling into the Navdata (it only did it once).

- It seems that those affects reports crashes "after takeoff", which is not very clear but, it might be when you are flying, but not yet over 10k maybe ?

If we could confirm that crashes happens only between after takeoff and below 10K, then we can be reasonably sure the problem is the Navdata API OR the Navdata *itself* and we already got multiple cases in the past where even a single duplicate Navaid crashed the sim even without GSX installed, and in one case the error was in the stock Navdata, another case it was in the Navigraph Navdata, but the real reason was the sim not gracefully handling duplicated data, and this was fixed later but, we can't be 100% sure that ALL issues related to Navdata have been completely found or solved

[thegreek]

Thanks Umberto for the clarification earlier.
To rule things out properly, I did a full set of tests over the last two days:

1. Full clean Navigraph reinstall:
I uninstalled all Navigraph components, removed every related folder (ProgramData, AppData, Community), rebooted, and then reinstalled only the current AIRAC cycle through the Navigraph Hub.
The installation completed without any errors.

2. Result:
The crashes with Couatl64_MSFS2024.exe → clr.dll (0xc0000005, offset 0x657c) continued to occur repeatedly during the flight.
Shortly afterward, this always leads to the usual FlightSimulator2024.exe → dxgi.dll (0xc0000005) and then the full CTD.
So the entire crash chain remained exactly the same even after a clean Navigraph setup.

3. GSX removed completely:
I then ran the exact same flight again (same aircraft, same route, same weather, same DX12/FG setup) with GSX fully removed from the system.
With GSX removed, the entire flight was completely stable with no clr.dll events, no ucrtbase.dll entries and no dxgi.dll CTD.

For that reason I don’t think this is a “GSX vs. Navigraph” conflict.
Both normally work together for many users.
In my case the issue only appears when Couatl64_MSFS2024.exe is active, and disappears entirely when it is removed.

One thing that might be relevant:
I am running MSFS 2024 SU4 Beta (1.6.23.0).
It’s possible that something introduced in SU4 (Navdata API or asynchronous changes) is triggering a scenario that doesn’t happen in the stable version, which would explain why it's harder to reproduce internally.

If helpful, I can provide the full crash reports / WER logs.
The signature is always identical:
Couatl64_MSFS2024.exe → clr.dll (0xc0000005) at offset 0x657c → followed by FlightSimulator2024.exe → dxgi.dll (0xc0000005)

Let me know if there’s anything specific I can provide to help narrow this down.

Best regards