MSFS 2024 network connection becomes unstable after 90 minutes on a laptop

User Support Hub Install, Performance & Graphics
, , , ,
1

Mods: This seems like the best place to put this. The suggested template didn’t seem appropriate.

Tl;dr: This is intended to be a comprehensive bug report. Details included are for the developers and anyone else who wants to think about it. Maybe detailing the problem and what I’ve tried that hasn’t worked might help.

So I’ve used MSFS 2024 since launch and after the initial trials and tribulations we all experienced, things got better and were stable. Recently, things have changed, and I’m really trying to figure out what the problem is. I’ll describe the problem, and the effects of various things I’ve tried.

The problem:

MSFS 2024 starts off as expected. During flights, usually around about 90 minutes into it, the network connection becomes “unstable” and MSFS bails on network errors. Eventually, after repeated failures, the application seems to affect the entire system, causing stuttered mouse movements and similar things. This resolves some time after MSFS 2024 either crashes or is terminated. A reboot of the computer resolves the situation immediately when the system comes back up.

System specs:

  • Intel Core Ultra 9 275HX 2700MHz 24 cores, 24 logical processors
  • Windows 11 Pro
  • 64GB system memory
  • RTX 5090 Laptop GPU, 24GB GDDR7 VRAM
  • SSDs in use obviously. (This isn’t on spinning rust.)
  • This occurs even when the Community folder is empty, so third party add-ons are not a factor.
  • Internet access: 1 Gbps symmetrical up and down, provided by Google Fiber/GFiber. Performance doesn’t always hit that on their own speed test (sometimes it’s 800 or so), but an Internet speed test on the computer in question consistently gets > 200Mbit/s to the speed test servers on the Internet. (Meaning speed PC-router is at least that.) The Internet connection itself is not interrupted when this problems occurs – it is exclusive to the MSFS streaming.

Observations:

  • On startup, MSFS does what I would expect it to. It pulls a large amount of data from multiple IP addresses. On a ‘netstat -bf’ the majority of these addresses don’t seem to resolve to a FQDN, so the tool just leaves it as a nameless IP address. The connection is over port 443 (https).
  • When loading into a new area, MSFS will have to stream scenery. That tracks with transfer rates of about 50Mbit/s over the connection. (There’s actually an expected range, but suffice to say it’s more than sufficient.)
  • At that point, MSFS works as expected. Fast forward to taking off and transiting areas requiring MSFS to continue to stream new scenery. This works as expected for some time, often up to about 90 minutes, but sometimes longer. There are frequent spikes in network activity as new scenery is loaded. This is as expected.
  • At some point, about 90 minutes in – though it is unclear whether this is time-dependent or somehow dependent on how much is streamed, though turning down scenery levels did appear to buy more time before this happens – MSFS begins complaining about an “unstable Internet connection.” Scenery becomes blurry, low bandwidth messages may appear (though this is relatively rare), and MSFS will periodically bail out to a screen saying that it requires a continuous Internet connection.
  • When watching network activity during this time, it appears that MSFS isn’t really trying. There are periodic spikes in received data, and MSFS will typically recover (“connection restored”), at least initially. Then the pattern repeats itself. I don’t recall ever having the simulator return to normal functionality once this stage is reached. The received data at this point is rather consistent, occuring at regular intervals with the same bandwidth, so that might not even be from MSFS. (If so, then MSFS is getting nothing back.
  • Unfortunately, I didn’t have a network analyzer available tonight to see for sure what processes that data was coming from, but it didn’t seem variable or large enough to be scenery responses from MSFS, and they topped out at about 3Mbps. Unless those spikes were just failure responses, at which point they seemed too large. (With the Windows task monitor, the only thing I can really do is look at the area under the curve as a relative approximation of the volume of data per incident.)

Troubleshooting tried and results:

  • Note: All other devices on the network continue to function normally. Initially, until the end stage, all other services (network or otherwise) are unaffected on the PC. Once everything gets sluggish, that changes. Once MSFS is terminated, the system eventually fully recovers.
  • Bandwidth bidirectionally on the PC’s connection is at least 200Mb/s. The actual pipe incoming to the router is usually > 900Mb/s. This does not change when MSFS starts misbehaving.
  • Complete reset of all network backbone devices (router, mesh extenders, etc) does not fix this.
  • When this occurs, closing MSFS, rebooting the PC immediately, then immediately running MSFS again (even without resetting network equipment) results in normal functionality returning, but this “syndrome” still recurs.
  • Flushing DNS caches (i.e., ‘ipconfig /flushdns’ as administrator) has no effect.
  • Connecting to Cloudflare Warp or Proton VPN (with any US-based node) doesn’t help the issue. All it does is throttle the connection bandwidth (of course).
  • Changing DNS to Cloudflare (1.1.1.1), Level3 (4.2.2.1), Google (8.8.8.8), or Quad9 (9.9.9.9) has no effect.
  • Whether IPv6 is available or not does not seem to affect this. If IPv6 is enabled, MSFS makes predominately IPv6 connections with some IPv4 mixed in. If IPv6 is not available, obviously it only makes IPv4 connections.
  • Even when all this is going on, ping time to other servers is as expected. I get about 12-14ms ping time to Cloudflare and Level3. Other sites seem to have ping times as expected. Pinging some of the IPv4 servers that MSFS connects to (like 20.201.200.96) is about 49ms. (Ping time like that is expected, and probably irrelevant given the nature of the bulk data transfers that are supposed to happen.)
  • Resetting all Windows network settings and drivers to their default state did not seem to change anything.
  • A flight can be made smoother if I run MSFS and first spawn into major scenery areas (like cities) that are along the flight route. The assumption is that this loads the scenery into the rolling cache so that enroute the simulator doesn’t have to stream it as it goes along. I verified this on a flight from KROA to KOPF: By precaching the route, I only had a couple of hiccups. MSFS’ default rolling cache size is 16GB, but I increased it to 128GB for this test. (This may help some troubleshooting, but is clearly not a solution.)
  • A complete removal of MSFS 2024 from the system and reinstall did not resolve the problem.
  • VRAM exhaustion is not the issue here. 24GB of dedicated VRAM, and I was using no more than 11.5GB or so during an entire test flight. (Verified with ‘Performance’ in Windows Task Manager.) Also, system RAM limits are never approached.
  • This is not saturation of GPU or CPU capacity. Both remained well within limits and mostly didn’t exceed about 60%. (Verified by Windows Task Manager.
3

I would suggest disconnecting all devices from the router and resetting the router to factory defaults, after making a backup of the current settings first.

Then, for the duration of the test, disable Wi-Fi on the router so that no other devices can automatically connect and affect the test.

Connect the laptop directly to the router using an Ethernet/LAN cable and test MSFS 2024 again.

EDIT

Also, I would suggest changing the topic title to something more specific, for example:

MSFS 2024 network connection becomes unstable after 90 minutes on a laptop.

5

Topic moved to User Support Hub since could be a user local issue and will allow users support as some guidance already provided by @TenPatrol .
Title updated to clearly describe what the issue is.

6

What a perfect report! I wish everybody documented issues this thoroughly.

The only information I think is still missing is the exact network chipset. The laptop model alone is not always enough, because manufacturers sometimes use different network adapters in otherwise identical machines — rather more often than one would hope.

I don’t know the current status of every network chipset, but in the recent past there have been several cases where hardware or driver problems caused intermittent connection issues. I had a Dell laptop with exactly that sort of problem, although in my case driver and firmware updates eventually solved it.

The fact that you only notice the problem in MSFS is actually quite plausible. What else are you running that would make a short or degraded connection obvious?

Windows will normally only warn you about a more substantial loss of connectivity. It certainly won’t pop up a message saying, “Your connection became rather poor for twelve seconds.” Applications such as Spotify use large buffers, while Netflix and similar services can buffer ahead or silently reduce quality. In normal use, you may therefore never notice brief drops or slowdowns at all.

What I would do is run a small script that checks the connection every 10 seconds and logs the result. Leave that running for a few hours, preferably during peak hours. That should tell you whether the laptop or network connection is occasionally misbehaving.

I would also run a traceroute to see the path between your laptop and the Microsoft servers. It is worth trying another MSFS server as well. You may find that one or more hops along the route are unusually slow or inconsistent. Searching for the relevant host or network provider can sometimes reveal a history of similar issues.

We had an example of that in Frankfurt last year, where a problematic hop caused connection issues for quite a few German users trying to reach the European servers.

Mathijs Kok
PMDG

7

Thanks for the reply. (Love PMDG products, btw.)

The network adapter is an “Killer™ Wi-Fi 7 BE1750w 320MHz Wireless Network Adapter (BE200D2W)”. I did pull all the bloatware that comes down the Intel Killer suite which I saw no benefit to and just complicated things.

I don’t see an obvious way to choose the server. Well, I do see under Settings->online where I can choose the “multiplayer” server. My only viable option is the US East Coast which has about a 50ms ping time. The others are significantly more distant. Since I’m not using multiplayer anything, I didn’t really pay attention to that.

Another thing is that I’ve tried forcing different routing. For example, I’ve connected directly, run it through Cloudflare Warp, and ran it through different Proton VPN end points. When I connect like that, I can test the connection through means other than MSFS, and logically the route from different end points are going to vary. It doesn’t seem to matter, as the connection seems to work for everything else.

I could also try a script that’s basically “ping -t” in a Powershell window and just look back to see if it’s crapping itself out randomly. You make a good point about the buffering, and MSFS is probably a lot less tolerant of intermittent problems.

I am in a suburban area, and the spectrum isn’t congested. I can see someone living in a Manhattan highrise having some serious issues.

By sheer coincidence, GFiber is coming out this afternoon to swap out their equipment for a completely different reason. Somehow I wouldn’t be surprised if it miraculously fixes itself.

Update 9/28/26: So GFiber came out and swapped out some network hardware, effectively upgrading me to WiFi 7 (802.11be). While the Internet bandwidth is actually higher, that doesn’t seem to be the problem. It was the “microfailure” rate and retransmissions eventually saturated the link. Everything is running quite smoothly now.

Update 9/29/26: Nope. After one successful flight, it’s back to the same nonsense again.

8

Okay, so here’s the deal. GFiber came out and swapped out some hardware, and in the process upgraded my connection from 1Gbps to 3Gbps. The actual backbone is getting at least 3Gbps (and ironically 4.5Gbps upload). Connected using Wi-Fi 7, good connection, roughly doubled the wireless throughput to the laptop to about 300Mbps or better. Still happens.

So then I decided to just cut to the chase and get the entire wireless question out of it. I snaked an Ethernet cable across the house. Connection is fine, and about 5ms less latency. Nope. Still happening.

This is totally on Asobo.

9

You have changed one very small part of a much larger network path. That does not eliminate your network adapter (wifi or cabled), its driver,s the motherboard/chipset, router, local network, ISP, peering, routing, or any of the intermediate infrastructure between your system and the Microsoft servers.

You also keep focusing on raw connection speed, but bandwidth was never the issue being discussed. A connection can easily deliver hundreds of Mbps while still suffering from packet loss, latency spikes, jitter, retransmissions, brief link drops, or poor routing. Any of those can affect MSFS without noticeably affecting buffered services such as YouTube, Netflix, or Spotify.

And there is a fairly simple sanity check here: if this were a general Asobo or Microsoft backend problem, it would not selectively affect one or two users. We would see a clear pattern across a much larger part of the user base, and this forum would be filling rapidly with identical reports.

That is not happening.

So while nobody can yet say exactly where the fault is, the available evidence points far more strongly toward something specific to your system, local network, ISP, or route to Microsoft’s infrastructure than toward a general Asobo issue. running hot with angry users. It is not.

Mathijs

10

I updated another post about this. It appears to have turned out to be something totally weird and unexpected.

Some antivirus program was installed (I think by the OEM, I don’t know) on this machine called Malwarebytes. I started looking through the process lists and saw this thing running. It is apparently a legitimate piece of software. Once I removed it, the problem seems to have resolved. I didn’t change any add-ons, Community stuff, or anything else.

So my suggestion for anyone having some weird-■■■ problem like this is to start going down the process list and removing bloatware. In this sense, that includes any antivirus software. You can always add things in one at a time later until something breaks.

Why a piece of antimalware software that appears legitimate would behave in this manner is a question for the ages. It only affected MSFS, and not even torrenting.

11

Looks like I was right when I mentioned in your other thread that programs running in the background could be one of the possible causes. Good that you found out which program was causing it.

12

Malwarebytes is one of the better security products available, and I would be very surprised if it were randomly blocking your connection to the Microsoft servers after you had already been connected for some time. If Malwarebytes did block something, you would normally get a notification and, more importantly, the event would be logged. It should therefore be relatively easy to confirm or rule out.

Also keep in mind that by disabling Malwarebytes, you have reduced the level of protection on your system. I have been using it myself for a loooong time, and I certainly would not leave it disabled unnecessarily.

That said, it is good to see that you are at least considering the possibility that the problem may not be on Asobo’s side. That opens up a lot more useful troubleshooting avenues.

Mathijs