Windows 11 SPP-Security Event ID 16394/16384

[Drewsky77]

Hello!

I'm new here and was hoping someone could help me with an issue I've been having. I play a few online MMOs, one of them being Elder Scrolls online. Since migrating to windows 11 in October, I've been getting disconnected from the game with no error code. I've explored all of the common troubleshooting for the game itself. However, I happened upon some odd logs in the event viewer that line up with the disconnects.

I will see a 16394 Event ID "Offline downlevel migration succeeded", which is apparently normal? However, it's being followed by Event ID 16384 "Successfully scheduled Software Protection service for re-start at 2125-12-14T21:52:20Z. Reason: RulesEngine." This log was from today at 3:52:20 PM CST.

When I search for others that have this issue, the forum often ends with them saying it "fixed itself" like it had been patched or otherwise. Some posts go back 5 years. Some are from early last year. I've ran DISM to try and repair any image issue. It doesn't seem to be flagging any corrupted files. I appreciate y'all. Thank you!

 

[ChatGPT]

Hi Drewsky77 — welcome.
From what you described, those SPP-Security (Software Protection Platform) events (16394 / 16384) are almost always Windows licensing/activation housekeeping and not a network stability indicator, so they’re very unlikely to be the reason ESO drops connection.
That said, one detail is worth attention:

1) Why does Event 16384 show a restart scheduled in the year 2125?​

Event ID 16384 (“Successfully scheduled Software Protection service for re-start at … Reason: RulesEngine.”) is typically benign, but a date like 2125-12-14 strongly suggests something is off with time handling on the PC (Windows time, BIOS/UEFI clock, or time sync).
Even if Windows looks correct in the tray, I’d verify it explicitly:

Check and force time sync​

1. Settings → Time & language → Date & time
   • Turn Set time automatically = On
   • Turn Set time zone automatically = On (or pick your correct time zone manually)
2. Open Command Prompt (Admin) and run:
   

   w32tm /query /status
   w32tm /resync

3. Reboot once and see if that “2125” scheduling keeps happening.

Also check BIOS/UEFI time: If the BIOS clock is wrong or drifting after shutdown, that can cause weird future timestamps. If it’s drifting, a weak CMOS battery is a common cause (especially on desktops, but it can happen on some laptops too).

Even if this doesn’t fix ESO disconnects, it’s still something you’ll want correct.

---

2) The more likely cause of ESO “silent” disconnects after moving to Windows 11​

Most “no error code” MMO disconnects come down to brief packet loss, Wi‑Fi roaming/power saving, router issues, or NIC driver/power management changes.

Quick high-value checks (Windows 11)​

A) Disable NIC power saving (very common fix)​

1. Right-click Start → Device Manager
2. Expand Network adapters
3. Right-click your adapter → Properties → Power Management
4. Uncheck:
   • Allow the computer to turn off this device to save power
5. Also check:
   • Control Panel → Power Options → Change plan settings → Advanced
   • Wireless Adapter Settings / PCI Express power saving (if present) → set to Maximum Performance

B) Update NIC drivers (don’t rely only on Windows Update)​

• If you’re on Intel/Killer/Realtek: install the latest driver from the PC/motherboard manufacturer first, or from Intel if it’s an Intel NIC/Wi‑Fi.

C) If on Wi‑Fi: test wired (even temporarily)​

If wired eliminates the disconnects, the problem is almost certainly Wi‑Fi stability/power/driver/router radio related.

---

3) Prove whether it’s a network drop (simple test)​

While playing, run a continuous ping in the background and leave it up when you disconnect:
Open Command Prompt and run:
ping -t 1.1.1.1
When ESO disconnects, alt-tab and see if you have “Request timed out” lines around that moment.

• If ping shows timeouts: it’s a network interruption (PC Wi‑Fi/NIC/router/ISP).
• If ping stays clean: it could be something else (driver reset, firewall/security software, ESO server-side, etc., but we then check different logs.

---

4) What I need from you to narrow it down​

1. Are you wired or Wi‑Fi when it happens?
2. Does it happen in other online games or only ESO?
3. In Event Viewer → Windows Logs → System, do you see anything at the disconnect time from:
   • e1rexpress / Netwtw / NDIS / Tcpip / DNS Client Events
   • WLAN-AutoConfig (if Wi‑Fi)
4. What is your network adapter model? (Device Manager → Network adapters list)

If you paste (or screenshot) a few System log warnings/errors from the exact disconnect timestamps (not the SPP ones), I can usually point to the real culprit pretty quickly.

 

[Drewsky77]

Hi Drewsky77 — welcome.
From what you described, those SPP-Security (Software Protection Platform) events (16394 / 16384) are almost always Windows licensing/activation housekeeping and not a network stability indicator, so they’re very unlikely to be the reason ESO drops connection.
That said, one detail is worth attention:

1) Why does Event 16384 show a restart scheduled in the year 2125?​

Event ID 16384 (“Successfully scheduled Software Protection service for re-start at … Reason: RulesEngine.”) is typically benign, but a date like 2125-12-14 strongly suggests something is off with time handling on the PC (Windows time, BIOS/UEFI clock, or time sync).
Even if Windows looks correct in the tray, I’d verify it explicitly:

Check and force time sync​

1. Settings → Time & language → Date & time
   • Turn Set time automatically = On
   • Turn Set time zone automatically = On (or pick your correct time zone manually)
2. Open Command Prompt (Admin) and run:
   

   w32tm /query /status
   w32tm /resync

3. Reboot once and see if that “2125” scheduling keeps happening.

Also check BIOS/UEFI time: If the BIOS clock is wrong or drifting after shutdown, that can cause weird future timestamps. If it’s drifting, a weak CMOS battery is a common cause (especially on desktops, but it can happen on some laptops too).

---

2) The more likely cause of ESO “silent” disconnects after moving to Windows 11​

Most “no error code” MMO disconnects come down to brief packet loss, Wi‑Fi roaming/power saving, router issues, or NIC driver/power management changes.

Quick high-value checks (Windows 11)​

A) Disable NIC power saving (very common fix)​

1. Right-click Start → Device Manager
2. Expand Network adapters
3. Right-click your adapter → Properties → Power Management
4. Uncheck:
   • Allow the computer to turn off this device to save power
5. Also check:
   • Control Panel → Power Options → Change plan settings → Advanced
   • Wireless Adapter Settings / PCI Express power saving (if present) → set to Maximum Performance

B) Update NIC drivers (don’t rely only on Windows Update)​

• If you’re on Intel/Killer/Realtek: install the latest driver from the PC/motherboard manufacturer first, or from Intel if it’s an Intel NIC/Wi‑Fi.

C) If on Wi‑Fi: test wired (even temporarily)​

If wired eliminates the disconnects, the problem is almost certainly Wi‑Fi stability/power/driver/router radio related.

---

3) Prove whether it’s a network drop (simple test)​

While playing, run a continuous ping in the background and leave it up when you disconnect:
Open Command Prompt and run:
ping -t 1.1.1.1
When ESO disconnects, alt-tab and see if you have “Request timed out” lines around that moment.

• If ping shows timeouts: it’s a network interruption (PC Wi‑Fi/NIC/router/ISP).
• If ping stays clean: it could be something else (driver reset, firewall/security software, ESO server-side, etc.), but we then check different logs.

---

4) What I need from you to narrow it down​

1. Are you wired or Wi‑Fi when it happens?
2. Does it happen in other online games or only ESO?
3. In Event Viewer → Windows Logs → System, do you see anything at the disconnect time from:
   • e1rexpress / Netwtw / NDIS / Tcpip / DNS Client Events
   • WLAN-AutoConfig (if Wi‑Fi)
4. What is your network adapter model? (Device Manager → Network adapters list)

If you paste (or screenshot) a few System log warnings/errors from the exact disconnect timestamps (not the SPP ones), I can usually point to the real culprit pretty quickly.

1) My system time was already set to sync automatically. I ran the prompts and BIOS/UEFI time matched my local time on reboot.
2) A. I unchecked the mentioned check box for my network adapter
2) B. I attempted to update my Realtek PCIe GbE Family Controller drivers through device manager, but it stated "The best drivers for your device are already installed".
2) C. My connection is wired.
3) I will perform this test and return with more info.
4) This does not happen on other online games. I will watch for the mentioned logs during the network drop test and return with my results. Thank you!

 

[ChatGPT]

Thanks for the detailed follow-up — that helps narrow it down a lot.
Since you’re wired, it doesn’t happen in other games, and Windows time looks correct, I’d treat the SPP 16394/16384 entries as background Windows licensing noise unless we find something else pointing to time jumps. The remaining likely buckets are:

• brief packet loss / link renegotiation (even on Ethernet)
• Realtek driver/EEE power features causing micro-drops
• security filtering (firewall/AV/VPN) affecting only ESO
• routing/path problem specific to ESO (ISP route to ESO megaserver)

Below are the most useful next steps.

---

1) Do a “two-target ping” test (this isolates where the drop is)​

When you can reproduce the disconnect, run both of these at the same time:

A) Ping your router (tests local link)​

1. Find your gateway:
   • ipconfig
   • Look for Default Gateway (example: 192.168.1.1)
2. Then:
   ping -t <your_gateway_ip>

B) Ping a reliable external IP (tests internet path)​

ping -t 1.1.1.1
What to look for when ESO disconnects:

• If gateway ping drops too → this is your PC ↔ router link (cable/port/NIC driver/EEE).
• If gateway stays solid but 1.1.1.1 drops → router/modem/ISP/line issue.
• If both stay solid → more likely ESO-specific filtering/routing (or the game client crashing its session without general packet loss).

If you want, you can also log to files:

ping -t 1.1.1.1 > "%USERPROFILE%\Desktop\ping_1.1.1.1.txt"
ping -t <gateway_ip> > "%USERPROFILE%\Desktop\ping_gateway.txt"

(Stop with Ctrl+C after the disconnect happens.

---

2) Don’t trust “best driver already installed” (Realtek)​

Device Manager often only confirms “best known to Windows Update”, not newest/stable.

Please tell me these two values:​

Device Manager → Network adapters → Realtek PCIe GbE Family Controller → Properties → Driver

• Driver Date
• Driver Version

Then update using one of these (in order):

1. Your motherboard / PC vendor support page (preferred)
2. If it’s a custom build and the board vendor is slow, then try the latest Realtek LAN driver from the board vendor anyway (ASUS/MSI/Gigabyte/ASRock often repackage Realtek’s driver best for their boards)

---

3) For Realtek Ethernet: disable the common “micro-drop” features (important)​

These settings frequently fix exactly the “random disconnect but everything else seems fine” symptom.
Device Manager → Network adapters → Realtek PCIe GbE Family Controller → Properties → Advanced
Try setting these (names vary slightly):

• Energy Efficient Ethernet (EEE) = Disabled
• Green Ethernet = Disabled
• Auto Disable Gigabit = Disabled (if present)
• Power Saving Mode = Disabled (if present)

Then reboot and test ESO again.
Also, in Power Management (you already did this part):

• Make sure Allow the computer to turn off this device to save power is unchecked.

---

4) Quick physical/network sanity checks (wired)​

Even if it “works most of the time”, ESO may be more sensitive to brief interruptions than other games.

• Try a different Ethernet cable (Cat5e/Cat6) and a different router/switch port
• Watch link speed: Settings → Network & Internet → Ethernet
  • Ensure it’s negotiating 1.0 Gbps (or whatever is expected)
• If you’re using powerline adapters, test without them (they can cause short drops)

---

5) ESO-specific filtering checks (since other games are fine)​

A few targeted questions (quick yes/no is fine):

1. Are you running any third-party antivirus/firewall (beyond Windows Security)?
2. Any VPN, “gaming optimizer”, QoS app, or traffic shaper?
3. Are you on the NA or EU megaserver?
4. When ESO disconnects, does it kick you all the way to login immediately, or “hang” for a while first?

Also, as a test: temporarily disable any third-party security/VPN and make sure eso64.exe is allowed through Windows Firewall (both Private/Public).

---

6) About that weird “2125” timestamp​

Now that you’ve verified Windows + BIOS time are correct, I’d consider it a cosmetic/buggy timestamp in that SPP event unless you see other signs of time discontinuity.
One quick validation:

• In Event Viewer, do you see other events around the disconnect with timestamps far in the future/past? If yes, we revisit time sync harder.

---

If you post back with:

• the results of the gateway ping vs 1.1.1.1 ping during a disconnect,
• your Realtek driver date/version,
• and any System log entries at the exact disconnect minute (especially from Dhcp-Client, NDIS, Tcpip, or anything mentioning link down/up),

…I can tell you pretty confidently which direction to go next.

 

[Drewsky77]

Thanks for the detailed follow-up — that helps narrow it down a lot.
Since you’re wired, it doesn’t happen in other games, and Windows time looks correct, I’d treat the SPP 16394/16384 entries as background Windows licensing noise unless we find something else pointing to time jumps. The remaining likely buckets are:

• brief packet loss / link renegotiation (even on Ethernet)
• Realtek driver/EEE power features causing micro-drops
• security filtering (firewall/AV/VPN) affecting only ESO
• routing/path problem specific to ESO (ISP route to ESO megaserver)

Below are the most useful next steps.

---

1) Do a “two-target ping” test (this isolates where the drop is)​

When you can reproduce the disconnect, run both of these at the same time:

A) Ping your router (tests local link)​

1. Find your gateway:
   • ipconfig
   • Look for Default Gateway (example: 192.168.1.1)
2. Then:
   ping -t <your_gateway_ip>

B) Ping a reliable external IP (tests internet path)​

ping -t 1.1.1.1
What to look for when ESO disconnects:

• If gateway ping drops too → this is your PC ↔ router link (cable/port/NIC driver/EEE).
• If gateway stays solid but 1.1.1.1 drops → router/modem/ISP/line issue.
• If both stay solid → more likely ESO-specific filtering/routing (or the game client crashing its session without general packet loss).

If you want, you can also log to files:

ping -t 1.1.1.1 > "%USERPROFILE%\Desktop\ping_1.1.1.1.txt"
ping -t <gateway_ip> > "%USERPROFILE%\Desktop\ping_gateway.txt"

(Stop with Ctrl+C after the disconnect happens.)

---

2) Don’t trust “best driver already installed” (Realtek)​

Device Manager often only confirms “best known to Windows Update”, not newest/stable.

Please tell me these two values:​

Device Manager → Network adapters → Realtek PCIe GbE Family Controller → Properties → Driver

• Driver Date
• Driver Version

Then update using one of these (in order):

1. Your motherboard / PC vendor support page (preferred)
2. If it’s a custom build and the board vendor is slow, then try the latest Realtek LAN driver from the board vendor anyway (ASUS/MSI/Gigabyte/ASRock often repackage Realtek’s driver best for their boards)

---

3) For Realtek Ethernet: disable the common “micro-drop” features (important)​

These settings frequently fix exactly the “random disconnect but everything else seems fine” symptom.
Device Manager → Network adapters → Realtek PCIe GbE Family Controller → Properties → Advanced
Try setting these (names vary slightly):

• Energy Efficient Ethernet (EEE) = Disabled
• Green Ethernet = Disabled
• Auto Disable Gigabit = Disabled (if present)
• Power Saving Mode = Disabled (if present)

Then reboot and test ESO again.
Also, in Power Management (you already did this part):

• Make sure Allow the computer to turn off this device to save power is unchecked.

---

4) Quick physical/network sanity checks (wired)​

Even if it “works most of the time”, ESO may be more sensitive to brief interruptions than other games.

• Try a different Ethernet cable (Cat5e/Cat6) and a different router/switch port
• Watch link speed: Settings → Network & Internet → Ethernet
  • Ensure it’s negotiating 1.0 Gbps (or whatever is expected)
• If you’re using powerline adapters, test without them (they can cause short drops)

---

5) ESO-specific filtering checks (since other games are fine)​

A few targeted questions (quick yes/no is fine):

1. Are you running any third-party antivirus/firewall (beyond Windows Security)?
2. Any VPN, “gaming optimizer”, QoS app, or traffic shaper?
3. Are you on the NA or EU megaserver?
4. When ESO disconnects, does it kick you all the way to login immediately, or “hang” for a while first?

Also, as a test: temporarily disable any third-party security/VPN and make sure eso64.exe is allowed through Windows Firewall (both Private/Public).

---

6) About that weird “2125” timestamp​

Now that you’ve verified Windows + BIOS time are correct, I’d consider it a cosmetic/buggy timestamp in that SPP event unless you see other signs of time discontinuity.
One quick validation:

• In Event Viewer, do you see other events around the disconnect with timestamps far in the future/past? If yes, we revisit time sync harder.

---

If you post back with:

• the results of the gateway ping vs 1.1.1.1 ping during a disconnect,
• your Realtek driver date/version,
• and any System log entries at the exact disconnect minute (especially from Dhcp-Client, NDIS, Tcpip, or anything mentioning link down/up),

…I can tell you pretty confidently which direction to go next.

You weren't wrong about the realtek drivers, they were dated back to 2021. It is updated for real this time. Driver date:10/3/2025 Driver version: 10.79.50.1003 . I also made the suggested changes in part 3. 4) Aggregated link speed is 1000mbps according to windows network information. 5) I have uninstalled the third party for the time being. I do not run any VPN or other game optimizer. I play on the NA megaserver. The in-game screen will freeze for a brief moment, less than a second. Then, it brings me to the login screen with a generic "an error occurred" with no error code to reference. 6) Often, but not every instance, has VSS Event ID 8224 "The VSS service is shutting down due to idle timeout."

I am redownloading the game and will get ping information once it's done. Thank you!

 

[ChatGPT]

Good catch on the Realtek driver age — moving from a 2021 NIC driver to a late‑2025 build is a very plausible fix for “random disconnect to login screen” symptoms after a Windows 11 migration.
A couple notes on what you reported:

About VSS Event ID 8224​

VSS 8224 (“VSS service is shutting down due to idle timeout”) is normal. VSS spins up when something requests it (backup, restore point, app snapshot), and it shuts down when idle. By itself it usually has nothing to do with network drops/game disconnects.

What I’d do next (in order)​

1) After the reinstall, do the 2-target ping test while playing​

This is still the fastest way to prove whether the game disconnect corresponds to a real network interruption.
Run both (in two separate Command Prompt windows):
A. Ping your router/gateway (local link test)

1. ipconfig → note Default Gateway
2. Then:
   ping -t <gateway_ip>

B. Ping a stable external IP (WAN/internet path test)
ping -t 1.1.1.1
When ESO kicks you to login, immediately alt-tab and see if either window shows timeouts.
Interpretation

• Gateway ping drops = PC↔router link issue (cable/port/NIC/driver/EEE/offload).
• Gateway ok, 1.1.1.1 drops = router/modem/ISP path issue.
• Both OK = more likely ESO-specific (routing/filtering/game client session), not a general loss.

If you can, let them log to files so we can match timestamps precisely:

ping -t 1.1.1.1 > "%USERPROFILE%\Desktop\ping_1.1.1.1.txt"
ping -t <gateway_ip> > "%USERPROFILE%\Desktop\ping_gateway.txt"

2) Pull the right Event Viewer entries at the disconnect minute​

The SPP events you originally found are almost certainly unrelated to connectivity.
Instead, check Event Viewer → Windows Logs → System at the exact minute of the disconnect and look specifically for:

• NDIS
• Tcpip
• Dhcp-Client
• DNS Client Events
• Anything that says link disconnected/reconnected, lease renewed, name resolution timeout, etc.

If you paste 5–10 lines around the timestamp, that’s usually enough.

3) If pings stay clean (no packet loss), we test ESO’s route specifically​

If both pings remain perfect when ESO disconnects, then I’d want the remote server IP ESO is connected to right before it drops, then run a trace to that.
Easiest way:

1. Open Resource Monitor (resmon)
2. Network tab → check eso64.exe
3. Under TCP Connections, note the Remote Address (IP)
4. Run:
   

   tracert <remote_ip>
   pathping <remote_ip>

That will tell us if there’s a bad hop/route that only affects ESO (NA megaserver path).

4) If gateway ping drops (local link issue), two quick isolates​

Even with the new driver + EEE/Green Ethernet disabled, if the gateway ping drops:

• Try a different Ethernet cable and a different router port
• If possible, test with a USB-to-Ethernet adapter for a day.
  If the problem vanishes on a different NIC, it strongly implicates the Realtek adapter/driver/advanced features.

---

A couple quick questions for your next reply​

1) When you get the next disconnect, do either pings show timeouts? (gateway / 1.1.1.1 / neither)
2) What router/modem model are you using? (Some have “gaming/QoS/DoS protection” features that can interrupt long-lived UDP flows.
3) If you can grab it: 5–10 System log lines around the disconnect timestamp (providers listed above).
Once you have the ping result, we can stop guessing and go straight to the correct fix path.

 

[Drewsky77]

Good catch on the Realtek driver age — moving from a 2021 NIC driver to a late‑2025 build is a very plausible fix for “random disconnect to login screen” symptoms after a Windows 11 migration.
A couple notes on what you reported:

About VSS Event ID 8224​

VSS 8224 (“VSS service is shutting down due to idle timeout”) is normal. VSS spins up when something requests it (backup, restore point, app snapshot), and it shuts down when idle. By itself it usually has nothing to do with network drops/game disconnects.

What I’d do next (in order)​

1) After the reinstall, do the 2-target ping test while playing​

This is still the fastest way to prove whether the game disconnect corresponds to a real network interruption.
Run both (in two separate Command Prompt windows):
A. Ping your router/gateway (local link test)

1. ipconfig → note Default Gateway
2. Then:
   ping -t <gateway_ip>

B. Ping a stable external IP (WAN/internet path test)
ping -t 1.1.1.1
When ESO kicks you to login, immediately alt-tab and see if either window shows timeouts.
Interpretation

• Gateway ping drops = PC↔router link issue (cable/port/NIC/driver/EEE/offload).
• Gateway ok, 1.1.1.1 drops = router/modem/ISP path issue.
• Both OK = more likely ESO-specific (routing/filtering/game client session), not a general loss.

If you can, let them log to files so we can match timestamps precisely:

ping -t 1.1.1.1 > "%USERPROFILE%\Desktop\ping_1.1.1.1.txt"
ping -t <gateway_ip> > "%USERPROFILE%\Desktop\ping_gateway.txt"

2) Pull the right Event Viewer entries at the disconnect minute​

The SPP events you originally found are almost certainly unrelated to connectivity.
Instead, check Event Viewer → Windows Logs → System at the exact minute of the disconnect and look specifically for:

• NDIS
• Tcpip
• Dhcp-Client
• DNS Client Events
• Anything that says link disconnected/reconnected, lease renewed, name resolution timeout, etc.

If you paste 5–10 lines around the timestamp, that’s usually enough.

3) If pings stay clean (no packet loss), we test ESO’s route specifically​

If both pings remain perfect when ESO disconnects, then I’d want the remote server IP ESO is connected to right before it drops, then run a trace to that.
Easiest way:

1. Open Resource Monitor (resmon)
2. Network tab → check eso64.exe
3. Under TCP Connections, note the Remote Address (IP)
4. Run:
   

   tracert <remote_ip>
   pathping <remote_ip>

That will tell us if there’s a bad hop/route that only affects ESO (NA megaserver path).

4) If gateway ping drops (local link issue), two quick isolates​

Even with the new driver + EEE/Green Ethernet disabled, if the gateway ping drops:

• Try a different Ethernet cable and a different router port
• If possible, test with a USB-to-Ethernet adapter for a day.
  If the problem vanishes on a different NIC, it strongly implicates the Realtek adapter/driver/advanced features.

---

A couple quick questions for your next reply​

1) When you get the next disconnect, do either pings show timeouts? (gateway / 1.1.1.1 / neither)
2) What router/modem model are you using? (Some have “gaming/QoS/DoS protection” features that can interrupt long-lived UDP flows.)
3) If you can grab it: 5–10 System log lines around the disconnect timestamp (providers listed above).
Once you have the ping result, we can stop guessing and go straight t

 

[ChatGPT]

Got it — and you’ve already made the two biggest “Windows 11 + Realtek” improvements: updating the NIC driver from 2021 to 10.79.50.1003 (10/3/2025) and disabling the common Realtek power-saving features.
At this point, the next disconnect after the reinstall is going to tell us which bucket we’re in (local link/NIC vs ISP/WAN vs ESO-only), and we can stop guessing.

1) When ESO disconnects again: run the “2-target ping” with timestamps​

Instead of plain ping -t, use this PowerShell version so you get exact timestamps you can match to Event Viewer:

A) Ping your gateway (local link)​

(Replace 192.168.1.1 with your Default Gateway from ipconfig.

while ($true) { $ts=(Get-Date).ToString("yyyy-MM-dd HH:mm:ss") if (Test-Connection 192.168.1.1 -Count 1 -Quiet) { "$ts gateway OK" } else { "$ts gateway TIMEOUT" } Start-Sleep -Seconds 1
} | Out-File "$env:USERPROFILE\Desktop\ping_gateway.txt" -Append

B) Ping an external IP (WAN/internet path)​

while ($true) { $ts=(Get-Date).ToString("yyyy-MM-dd HH:mm:ss") if (Test-Connection 1.1.1.1 -Count 1 -Quiet) { "$ts 1.1.1.1 OK" } else { "$ts 1.1.1.1 TIMEOUT" } Start-Sleep -Seconds 1
} | Out-File "$env:USERPROFILE\Desktop\ping_1.1.1.1.txt" -Append

What I need from you after the next disconnect:

• Did you see gateway TIMEOUT, 1.1.1.1 TIMEOUT, or neither?

This is still the single most important fork in the road.

---

2) Grab the relevant System events for the exact minute​

The SPP events are almost certainly unrelated to the disconnect symptoms you described.
And VSS 8224 “idle timeout” is usually normal/benign (VSS starts when requested, then stops when idle), so I wouldn’t treat it as the cause unless we see it paired with an actual network stack reset event.
Here’s an easy way to extract the network-related System events right after a disconnect:

1. Note the exact local time the disconnect happened (to the minute).
2. Run this in PowerShell (Admin):
   

   $start = (Get-Date).AddMinutes(-10)
   Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start} |
   Where-Object { $_.ProviderName -match 'NDIS|Tcpip|Dhcp|DNS Client Events|Realtek' } |
   Select-Object TimeCreated, ProviderName, Id, Message |
   Format-List

Paste what it outputs (even 10–30 lines is fine).

---

3) If both pings stay perfect (no timeouts)​

Then the PC’s connection is staying up, and we pivot to ESO-specific path/filtering:

• Tell me your router/modem model (brand + model number).
• Then we’ll capture the remote server IP ESO is connected to (Resource Monitor → Network tab → eso64.exe → Remote Address), and run a tracert/pathping to that IP.

---

4) One extra Realtek tweak only if the issue persists after the driver update​

If you still get disconnects and the logs/pings suggest a local/NIC hiccup, we’ll try this (reversible, low risk):
Device Manager → Realtek PCIe GbE Family Controller → Advanced

• Large Send Offload v2 (IPv4) = Disabled
• Large Send Offload v2 (IPv6) = Disabled
• Interrupt Moderation = Disabled (sometimes helps latency-sensitive games)
• Keep EEE / Green Ethernet disabled (you already did this).

(We’ll do this only if your ping/log results point to the NIC/link layer.

---

If you reply with:
1) the first few lines around the disconnect time from ping_gateway.txt and ping_1.1.1.1.txt, and
2) the PowerShell event output above,
…I can tell you very quickly whether we’re dealing with NIC/link, ISP/WAN, or ESO-only routing/filtering and give you the next exact fix step.

 

[Drewsky77]

Good catch on the Realtek driver age — moving from a 2021 NIC driver to a late‑2025 build is a very plausible fix for “random disconnect to login screen” symptoms after a Windows 11 migration.
A couple notes on what you reported:

About VSS Event ID 8224​

VSS 8224 (“VSS service is shutting down due to idle timeout”) is normal. VSS spins up when something requests it (backup, restore point, app snapshot), and it shuts down when idle. By itself it usually has nothing to do with network drops/game disconnects.

What I’d do next (in order)​

1) After the reinstall, do the 2-target ping test while playing​

This is still the fastest way to prove whether the game disconnect corresponds to a real network interruption.
Run both (in two separate Command Prompt windows):
A. Ping your router/gateway (local link test)

1. ipconfig → note Default Gateway
2. Then:
   ping -t <gateway_ip>

B. Ping a stable external IP (WAN/internet path test)
ping -t 1.1.1.1
When ESO kicks you to login, immediately alt-tab and see if either window shows timeouts.
Interpretation

• Gateway ping drops = PC↔router link issue (cable/port/NIC/driver/EEE/offload).
• Gateway ok, 1.1.1.1 drops = router/modem/ISP path issue.
• Both OK = more likely ESO-specific (routing/filtering/game client session), not a general loss.

If you can, let them log to files so we can match timestamps precisely:

ping -t 1.1.1.1 > "%USERPROFILE%\Desktop\ping_1.1.1.1.txt"
ping -t <gateway_ip> > "%USERPROFILE%\Desktop\ping_gateway.txt"

2) Pull the right Event Viewer entries at the disconnect minute​

The SPP events you originally found are almost certainly unrelated to connectivity.
Instead, check Event Viewer → Windows Logs → System at the exact minute of the disconnect and look specifically for:

• NDIS
• Tcpip
• Dhcp-Client
• DNS Client Events
• Anything that says link disconnected/reconnected, lease renewed, name resolution timeout, etc.

If you paste 5–10 lines around the timestamp, that’s usually enough.

3) If pings stay clean (no packet loss), we test ESO’s route specifically​

If both pings remain perfect when ESO disconnects, then I’d want the remote server IP ESO is connected to right before it drops, then run a trace to that.
Easiest way:

1. Open Resource Monitor (resmon)
2. Network tab → check eso64.exe
3. Under TCP Connections, note the Remote Address (IP)
4. Run:
   

   tracert <remote_ip>
   pathping <remote_ip>

That will tell us if there’s a bad hop/route that only affects ESO (NA megaserver path).

4) If gateway ping drops (local link issue), two quick isolates​

Even with the new driver + EEE/Green Ethernet disabled, if the gateway ping drops:

• Try a different Ethernet cable and a different router port
• If possible, test with a USB-to-Ethernet adapter for a day.
  If the problem vanishes on a different NIC, it strongly implicates the Realtek adapter/driver/advanced features.

---

A couple quick questions for your next reply​

1) When you get the next disconnect, do either pings show timeouts? (gateway / 1.1.1.1 / neither)
2) What router/modem model are you using? (Some have “gaming/QoS/DoS protection” features that can interrupt long-lived UDP flows.)
3) If you can grab it: 5–10 System log lines around the disconnect timestamp (providers listed above).
Once you have the ping result, we can stop guessing and go straight to the correct fix path.

1) I was able to reproduce the disconnection while doing the 2 ping test. However, neither console displayed a time out of any sort. There are also wasn't any abnormally high ping. Furthermore, no system logs were generated near the 7:22 pm cst time stamp.

 

[ChatGPT]

Nice job reproducing it while running the 2-ping test — that result is very informative.

What your result means​

If, at the moment ESO kicked you to the login screen (you said Jan 7, 2026 ~7:22 PM CST), both:

• ping to your gateway/router, and
• ping to 1.1.1.1

stayed clean (no timeouts / no spike), then you did not have a general connectivity drop. That strongly points away from the Realtek link “micro-drop” theory and toward an ESO-session-specific interruption (route/peering issue to ESO, NAT/UDP state timing out/resetting, or something filtering only that traffic).
Also, your Event Viewer screenshot shows only “Information” items like HttpService 113/114 and Service Control Manager 7040, plus Kernel-Power 566 earlier—nothing network-stack-related in that window. So it makes sense you didn’t find NDIS/Tcpip/DHCP events near the disconnect. (That screenshot is around 6:27 PM–7:26 PM on Jan 7, 2026 and doesn’t show network providers.

---

Next step (this is the key): capture ESO’s remote IP at the moment it happens​

We need to test the path to the actual ESO server you’re connected to, because 1.1.1.1 can be fine while the specific route to ESO has loss/reset.

A) Find the ESO server IP​

1. Start ESO and log in.
2. Open Resource Monitor (resmon)
3. Go to Network tab
4. Check eso64.exe
5. In TCP Connections, note the Remote Address (IP) and the Remote Port

B) Run a WinMTR/PingPlotter-style test to that IP​

Best: WinMTR (continuous + shows where loss starts).

• Run WinMTR to that Remote Address
• Let it run until you get kicked
• Save the results

If you don’t want extra tools yet, do at least:

tracert <eso_server_ip>
pathping <eso_server_ip>

Important: some servers block ICMP ping, so lack of ping replies doesn’t always mean failure. That’s why WinMTR (and/or pathping/tracert) plus the timing is helpful.

---

If the ESO remote IP changes quickly / is hard to catch​

Alternative: grab the connection table from PowerShell while you’re playing:

Get-NetTCPConnection -OwningProcess (Get-Process eso64).Id | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State

Run it once while connected, and again right after the disconnect.

---

Two quick “low risk” tests you can do in parallel (because they’re common ESO fixes)​

These don’t require guessing the root cause yet:

1) Temporarily disable IPv6 on your Ethernet adapter (test only)​

• Control Panel → Network Connections → right-click Ethernet → Properties
• Uncheck Internet Protocol Version 6 (TCP/IPv6)
• Test ESO for a session

(If no change, turn it back on.

2) Change DNS (rules out DNS oddities, even though your pings were fine)​

Set IPv4 DNS to:

• 1.1.1.1 and 1.0.0.1 (Cloudflare) or
• 8.8.8.8 and 8.8.4.4 (Google)

Then:
ipconfig /flushdns

---

Two questions that will help target this fast​

1) What is your router/modem model? (Exact brand/model)
2) Are you connected directly to the ISP modem/router, or through a second router/switch?
Once you post the ESO Remote Address/Port (and ideally a WinMTR or tracert/pathping to it), we’ll be able to tell whether this is:

• an ISP/peering route issue to the ESO NA megaserver path, or
• a local NAT/firewall/router feature interrupting long-lived game traffic even while ICMP stays perfect.

 

[Drewsky77]

Nice job reproducing it while running the 2-ping test — that result is very informative.

What your result means​

If, at the moment ESO kicked you to the login screen (you said Jan 7, 2026 ~7:22 PM CST), both:

• ping to your gateway/router, and
• ping to 1.1.1.1

stayed clean (no timeouts / no spike), then you did not have a general connectivity drop. That strongly points away from the Realtek link “micro-drop” theory and toward an ESO-session-specific interruption (route/peering issue to ESO, NAT/UDP state timing out/resetting, or something filtering only that traffic).
Also, your Event Viewer screenshot shows only “Information” items like HttpService 113/114 and Service Control Manager 7040, plus Kernel-Power 566 earlier—nothing network-stack-related in that window. So it makes sense you didn’t find NDIS/Tcpip/DHCP events near the disconnect. (That screenshot is around 6:27 PM–7:26 PM on Jan 7, 2026 and doesn’t show network providers.)

---

Next step (this is the key): capture ESO’s remote IP at the moment it happens​

We need to test the path to the actual ESO server you’re connected to, because 1.1.1.1 can be fine while the specific route to ESO has loss/reset.

A) Find the ESO server IP​

1. Start ESO and log in.
2. Open Resource Monitor (resmon)
3. Go to Network tab
4. Check eso64.exe
5. In TCP Connections, note the Remote Address (IP) and the Remote Port

B) Run a WinMTR/PingPlotter-style test to that IP​

Best: WinMTR (continuous + shows where loss starts).

• Run WinMTR to that Remote Address
• Let it run until you get kicked
• Save the results

If you don’t want extra tools yet, do at least:

tracert <eso_server_ip>
pathping <eso_server_ip>

Important: some servers block ICMP ping, so lack of ping replies doesn’t always mean failure. That’s why WinMTR (and/or pathping/tracert) plus the timing is helpful.

---

If the ESO remote IP changes quickly / is hard to catch​

Alternative: grab the connection table from PowerShell while you’re playing:

Get-NetTCPConnection -OwningProcess (Get-Process eso64).Id |
  Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State

Run it once while connected, and again right after the disconnect.

---

Two quick “low risk” tests you can do in parallel (because they’re common ESO fixes)​

These don’t require guessing the root cause yet:

1) Temporarily disable IPv6 on your Ethernet adapter (test only)​

• Control Panel → Network Connections → right-click Ethernet → Properties
• Uncheck Internet Protocol Version 6 (TCP/IPv6)
• Test ESO for a session

(If no change, turn it back on.)

2) Change DNS (rules out DNS oddities, even though your pings were fine)​

Set IPv4 DNS to:

• 1.1.1.1 and 1.0.0.1 (Cloudflare) or
• 8.8.8.8 and 8.8.4.4 (Google)

Then:
ipconfig /flushdns

---

Two questions that will help target this fast​

1) What is your router/modem model? (Exact brand/model)
2) Are you connected directly to the ISP modem/router, or through a second router/switch?
Once you post the ESO Remote Address/Port (and ideally a WinMTR or tracert/pathping to it), we’ll be able to tell whether this is:

• an ISP/peering route issue to the ESO NA megaserver path, or
• a local NAT/firewall/router feature interrupting long-lived game traffic even while ICMP stays perfect.

Router is Arris SB8200, router is tp link Ax1800

"
tracert 198.20.200.23

Tracing route to 198.20.200.23 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.0.1
2 23 ms 7 ms 10 ms ip-69-10-96-1.midstate.ip.cablemo.net [69.10.96.1]
3 * * * Request timed out.
4 14 ms 9 ms 8 ms strbmo-lcore1-hun0012.fidnet.com [216.229.73.194]
5 10 ms 9 ms 11 ms rollmo-lcore2-bnd6.fidnet.com [216.229.73.208]
6 9 ms 9 ms 10 ms snhlar-core1-bnd6.fidnet.com [216.229.73.72]
7 14 ms 12 ms 11 ms sllvmo-lcore1-bnd11.fidnet.com [216.229.73.144]
8 13 ms 11 ms 11 ms cubamo-sw01-vln1100.fidnet.com [216.229.73.20]
9 12 ms 16 ms 9 ms grldmo-core1-bnd4.fidnet.com [216.229.74.49]
10 17 ms 12 ms 12 ms nwhnmo-core1-bnd2.fidnet.com [216.229.74.50]
11 13 ms 17 ms 31 ms stl-asr9010-bnd7.fidnet.com [216.229.74.54]
12 13 ms 12 ms 16 ms 67-60-16-157.cpe.sparklight.net [67.60.16.157]
13 17 ms 42 ms 19 ms 10.224.253.233
14 18 ms 24 ms 19 ms 10.224.253.233
15 46 ms 17 ms 21 ms chi-b23-link.ip.twelve99.net [62.115.56.192]
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete."
"
pathping 198.20.200.23

Tracing route to 198.20.200.23 over a maximum of 30 hops

0 Drewsky [192.168.0.137]
1 192.168.0.1
2 ip-69-10-96-1.midstate.ip.cablemo.net [69.10.96.1]
3 * * *
Computing statistics for 50 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 Drewsky [192.168.0.137]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.0.1
0/ 100 = 0% |
2 14ms 0/ 100 = 0% 0/ 100 = 0% ip-69-10-96-1.midstate.ip.cablemo.net [69.10.96.1]

Trace complete."

 

[ChatGPT]

Thanks — that’s exactly the kind of data we needed.

1) Interpreting your tracert / pathping results​

Why tracert shows lots of Request timed out​

That does not automatically mean your route is broken.

• Many ISP/core routers do not reply to ICMP TTL-expired messages (what tracert relies on), so you’ll see * * * even when traffic is passing through fine.
• Some destinations (and upstream networks) also block ICMP echo and/or rate-limit it.

So the fact that your trace stops responding after hop 15/16 is not, by itself, proof of a problem—especially since you can actively play and your gateway/1.1.1.1 pings stayed stable at the disconnect time.

Why pathping stops at hop 3​

pathping can’t compute loss stats unless it can “see” the intermediate hops. Since hop 3 doesn’t reply to ICMP, pathping can’t continue.
Bottom line: these traces mostly tell us “ICMP is filtered somewhere,” not “ESO is dropping because the internet is dropping.”

---

2) The key remaining suspect: something that affects ESO specifically (often router/NAT/firewall behavior)​

You’re on:

• Modem: Arris SB8200
• Router: TP-Link AX1800
  …and your general connectivity tests didn’t blip when ESO kicked you out.

That’s a classic setup where the next best isolation test is:

3) Isolation test (high value): bypass the TP-Link router for 10–20 minutes​

This cleanly answers “is the TP-Link causing the ESO session drops?”

1. Power off the SB8200 modem.
2. Disconnect the TP-Link router from the modem.
3. Connect your PC directly to the SB8200 with Ethernet.
4. Power on the SB8200 and wait for it to fully come online.
5. Reboot the PC (or at least disable/enable Ethernet) so it grabs the public IP.
6. Launch ESO and play until you’d normally see a disconnect.

Result interpretation:

• If the disconnect stops when direct-to-modem: the TP-Link router settings/firmware/NAT behavior is the likely cause.
• If it still disconnects direct-to-modem: more likely ISP path/peering to ESO or something on the PC/game client itself.

(After the test, hook the router back up; you may need to power-cycle the modem again so it gives the router a public IP.

---

4) One thing I still need: the ESO “Remote Port”​

You traced 198.20.200.23, which is great, but to test properly we need the Remote Port shown in Resource Monitor next to that IP.
Please reply with:

• ESO Remote Address (you have: 198.20.200.23)
• ESO Remote Port (example format: 24507, etc.

Then we can run a port-level connectivity check that’s more relevant than ICMP:
Test-NetConnection 198.20.200.23 -Port <REMOTE_PORT> -InformationLevel Detailed

---

5) If the router is implicated: TP-Link settings to try (quick list)​

If the bypass test points to the TP-Link AX1800, these are the most common fixes:

1. Update TP-Link firmware (important).
2. Temporarily disable (for testing):
   • QoS / “Game Accelerator” / Traffic prioritization
   • DoS protection / SPI firewall (only as a short test)
3. Ensure UPnP is enabled (test with it on).
4. If you have IPv6 enabled on the router, try disabling IPv6 there too (for testing).

---

Next reply: what I need​

1) Did you test direct-to-modem, and what happened?
2) What is ESO’s Remote Port for 198.20.200.23 (from Resource Monitor)?
With those two answers, we can narrow it to either “TP-Link router behavior” vs “upstream/ESO path” and give you a targeted fix instead of generic networking steps.

 

[Drewsky77]

Thanks — that’s exactly the kind of data we needed.

1) Interpreting your tracert / pathping results​

Why tracert shows lots of Request timed out​

That does not automatically mean your route is broken.

• Many ISP/core routers do not reply to ICMP TTL-expired messages (what tracert relies on), so you’ll see * * * even when traffic is passing through fine.
• Some destinations (and upstream networks) also block ICMP echo and/or rate-limit it.

So the fact that your trace stops responding after hop 15/16 is not, by itself, proof of a problem—especially since you can actively play and your gateway/1.1.1.1 pings stayed stable at the disconnect time.

Why pathping stops at hop 3​

pathping can’t compute loss stats unless it can “see” the intermediate hops. Since hop 3 doesn’t reply to ICMP, pathping can’t continue.
Bottom line: these traces mostly tell us “ICMP is filtered somewhere,” not “ESO is dropping because the internet is dropping.”

---

2) The key remaining suspect: something that affects ESO specifically (often router/NAT/firewall behavior)​

You’re on:

• Modem: Arris SB8200
• Router: TP-Link AX1800
  …and your general connectivity tests didn’t blip when ESO kicked you out.

That’s a classic setup where the next best isolation test is:

3) Isolation test (high value): bypass the TP-Link router for 10–20 minutes​

This cleanly answers “is the TP-Link causing the ESO session drops?”

1. Power off the SB8200 modem.
2. Disconnect the TP-Link router from the modem.
3. Connect your PC directly to the SB8200 with Ethernet.
4. Power on the SB8200 and wait for it to fully come online.
5. Reboot the PC (or at least disable/enable Ethernet) so it grabs the public IP.
6. Launch ESO and play until you’d normally see a disconnect.

Result interpretation:

• If the disconnect stops when direct-to-modem: the TP-Link router settings/firmware/NAT behavior is the likely cause.
• If it still disconnects direct-to-modem: more likely ISP path/peering to ESO or something on the PC/game client itself.

(After the test, hook the router back up; you may need to power-cycle the modem again so it gives the router a public IP.)

---

4) One thing I still need: the ESO “Remote Port”​

You traced 198.20.200.23, which is great, but to test properly we need the Remote Port shown in Resource Monitor next to that IP.
Please reply with:

• ESO Remote Address (you have: 198.20.200.23)
• ESO Remote Port (example format: 24507, etc.)

Then we can run a port-level connectivity check that’s more relevant than ICMP:
Test-NetConnection 198.20.200.23 -Port <REMOTE_PORT> -InformationLevel Detailed

---

5) If the router is implicated: TP-Link settings to try (quick list)​

If the bypass test points to the TP-Link AX1800, these are the most common fixes:

1. Update TP-Link firmware (important).
2. Temporarily disable (for testing):
   • QoS / “Game Accelerator” / Traffic prioritization
   • DoS protection / SPI firewall (only as a short test)
3. Ensure UPnP is enabled (test with it on).
4. If you have IPv6 enabled on the router, try disabling IPv6 there too (for testing).

---

Next reply: what I need​

1) Did you test direct-to-modem, and what happened?
2) What is ESO’s Remote Port for 198.20.200.23 (from Resource Monitor)?
With those two answers, we can narrow it to either “TP-Link router behavior” vs “upstream/ESO path” and give you a targeted fix instead of generic networking steps.

Remote port is 24506 for the remote address I traced. There is a second remote address and remote port, though

 

[ChatGPT]

Great — 24506 is exactly what we needed. And yes, it’s normal to see more than one remote IP/port for an MMO (login/megaserver, voice/chat, web/CDN, etc.. The trick is figuring out which connection is the “gameplay” one at the moment you get kicked.

1) First: capture all ESO remote connections (so we don’t chase the wrong IP)​

While you’re logged into the game (ideally in an area where it tends to disconnect), run this in PowerShell:

$pid = (Get-Process eso64).Id
Get-NetTCPConnection -OwningProcess $pid | Sort-Object RemoteAddress, RemotePort | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State

Paste the output here (you can redact your local IP if you want, but keep the remote IPs/ports).
That will tell us the second remote address/port and which ones are actually established.

---

2) Do a TCP reachability check to the ESO IPort (quick sanity check)​

Since Resource Monitor showed this under TCP Connections, this is a valid test:
Test-NetConnection 198.20.200.23 -Port 24506 -InformationLevel Detailed

• If it shows TcpTestSucceeded : True, it means basic TCP reachability to that endpoint is fine at that moment.
• If it’s False (especially while you’re otherwise online), that’s strong evidence of a path/filter issue.

(If the second remote IP is different, run the same command for that one too.

---

3) Still the highest-value isolation test: bypass the TP-Link (briefly)​

Because your gateway ping and 1.1.1.1 ping stayed clean during the kick, this is increasingly likely to be router/NAT/firewall behavior or ISP routing specific to ESO, not a general “internet drop.”
If you haven’t yet, the clean isolation is:

• Connect PC directly to the SB8200 for 10–20 minutes and test ESO.
• Keep Windows Firewall on and avoid random browsing during the test (you’ll be directly exposed to the internet).

If the disconnects stop direct-to-modem, we focus 100% on the TP-Link settings/firmware.

---

4) If it is the TP-Link AX1800: the most relevant toggles to test​

Do these one at a time (so we know what helped):

1. Update router firmware
2. Disable for testing:
   • QoS / Traffic Prioritization / Game Accelerator
   • DoS protection / SPI firewall
3. Toggle UPnP (try enabled if it’s off)

---

What to send next​

1) The PowerShell connection list (so we get the second remote address/port).
2) The output of Test-NetConnection 198.20.200.23 -Port 24506 ...
3) Whether you tried direct-to-modem, and if ESO still kicked you.
Once I see the second remote endpoint + whether TCP reachability is clean, we can decide whether to pursue router features, ISP/peering, or a PC-side packet capture to confirm if the server/router is sending a TCP reset at the kick moment.

 

[datawizard0103]

Hello!

I'm new here and was hoping someone could help me with an issue I've been having. I play a few online MMOs, one of them being Elder Scrolls online. Since migrating to windows 11 in October, I've been getting disconnected from the game with no error code. I've explored all of the common troubleshooting for the game itself. However, I happened upon some odd logs in the event viewer that line up with the disconnects.

I will see a 16394 Event ID "Offline downlevel migration succeeded", which is apparently normal? However, it's being followed by Event ID 16384 "Successfully scheduled Software Protection service for re-start at 2125-12-14T21:52:20Z. Reason: RulesEngine." This log was from today at 3:52:20 PM CST.

When I search for others that have this issue, the forum often ends with them saying it "fixed itself" like it had been patched or otherwise. Some posts go back 5 years. Some are from early last year. I've ran DISM to try and repair any image issue. It doesn't seem to be flagging any corrupted files. I appreciate y'all. Thank you!

Those two event IDs are basically noise and not what’s kicking you out of ESO. Software Protection restarts happen quietly on Windows 11 and don’t touch your network stack. What does line up with random MMO disconnects after upgrading is Windows 11 being aggressive with network power saving. If you’re on Wi-Fi or even Ethernet, go into Device Manager, open your network adapter, and turn off any power saving or “allow the computer to turn off this device” option. Also disable Wi-Fi roaming aggressiveness if it’s there. I’ve seen this cause brief drops that games hate but Windows barely notices. If possible, test on a wired connection for a day. If the issue disappears, you’ve found the real culprit.

 

[Drewsky77]

Those two event IDs are basically noise and not what’s kicking you out of ESO. Software Protection restarts happen quietly on Windows 11 and don’t touch your network stack. What does line up with random MMO disconnects after upgrading is Windows 11 being aggressive with network power saving. If you’re on Wi-Fi or even Ethernet, go into Device Manager, open your network adapter, and turn off any power saving or “allow the computer to turn off this device” option. Also disable Wi-Fi roaming aggressiveness if it’s there. I’ve seen this cause brief drops that games hate but Windows barely notices. If possible, test on a wired connection for a day. If the issue disappears, you’ve found the real culprit.

I appreciate your help on the matter, thank you. I had turned off the network adapter power saving, as suggested by ChatGPT. Unfortunately, I was still able to reproduce the error. I'll definitely try out disabling wifi roaming, though. Would that still matter when I'm using a line connection?

 

[Drewsky77]

Great — 24506 is exactly what we needed. And yes, it’s normal to see more than one remote IP/port for an MMO (login/megaserver, voice/chat, web/CDN, etc.). The trick is figuring out which connection is the “gameplay” one at the moment you get kicked.

1) First: capture all ESO remote connections (so we don’t chase the wrong IP)​

While you’re logged into the game (ideally in an area where it tends to disconnect), run this in PowerShell:

$pid = (Get-Process eso64).Id
Get-NetTCPConnection -OwningProcess $pid |
  Sort-Object RemoteAddress, RemotePort |
  Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State

Paste the output here (you can redact your local IP if you want, but keep the remote IPs/ports).
That will tell us the second remote address/port and which ones are actually established.

---

2) Do a TCP reachability check to the ESO IPort (quick sanity check)​

Since Resource Monitor showed this under TCP Connections, this is a valid test:
Test-NetConnection 198.20.200.23 -Port 24506 -InformationLevel Detailed

• If it shows TcpTestSucceeded : True, it means basic TCP reachability to that endpoint is fine at that moment.
• If it’s False (especially while you’re otherwise online), that’s strong evidence of a path/filter issue.

(If the second remote IP is different, run the same command for that one too.)

---

3) Still the highest-value isolation test: bypass the TP-Link (briefly)​

Because your gateway ping and 1.1.1.1 ping stayed clean during the kick, this is increasingly likely to be router/NAT/firewall behavior or ISP routing specific to ESO, not a general “internet drop.”
If you haven’t yet, the clean isolation is:

• Connect PC directly to the SB8200 for 10–20 minutes and test ESO.
• Keep Windows Firewall on and avoid random browsing during the test (you’ll be directly exposed to the internet).

If the disconnects stop direct-to-modem, we focus 100% on the TP-Link settings/firmware.

---

4) If it is the TP-Link AX1800: the most relevant toggles to test​

Do these one at a time (so we know what helped):

1. Update router firmware
2. Disable for testing:
   • QoS / Traffic Prioritization / Game Accelerator
   • DoS protection / SPI firewall
3. Toggle UPnP (try enabled if it’s off)

---

What to send next​

1) The PowerShell connection list (so we get the second remote address/port).
2) The output of Test-NetConnection 198.20.200.23 -Port 24506 ...
3) Whether you tried direct-to-modem, and if ESO still kicked you.
Once I see the second remote endpoint + whether TCP reachability is clean, we can decide whether to pursue router features, ISP/peering, or a PC-side packet capture to confirm if the server/router is sending a TCP reset at the kick moment.

I still need to do your suggested tests, but I was able to reproduce the error on a different PC using the same network.

 

[ChatGPT]

That’s an important finding: if you can reproduce the same ESO kick-to-login behavior on a different PC on the same home network, it makes a per-PC Windows 11 issue (SPP events, NIC driver quirks, local firewall on one machine, etc. much less likely. It pushes us toward router/NAT behavior, ISP path/peering, or something ESO-specific.
You’re on an Arris SB8200 modem + TP-Link AX1800 router, and you already identified an ESO endpoint like 198.20.200.23:24506.

1) Quick clarification (helps choose the right branch)​

On the second PC, was it:

• the same ESO account or a different account?
• connected wired to the TP-Link as well?
• disconnecting at the same time as the first PC, or independently?

If it’s two PCs dropping at the same time, that’s almost certainly router/ISP. If it’s independent, it can still be router/ISP/route, but it’s more “session/path” than “whole internet.”

2) Highest-value test now: bypass the TP-Link router (one PC, 10–20 minutes)​

This is still the cleanest way to separate router/NAT vs ISP/route.
Steps (summary):

1. Power off the SB8200.
2. Disconnect SB8200 ↔ TP-Link.
3. Connect PC directly to SB8200 via Ethernet.
4. Power SB8200 back on, wait fully online.
5. Reboot PC (or disable/enable Ethernet).
6. Test ESO until you’d normally get kicked.

Important safety note: when you’re direct-to-modem, keep Windows Firewall ON and don’t do casual browsing—just test the game.

Result interpretation​

• If ESO stops disconnecting direct-to-modem: the TP-Link router is the culprit (firmware/features/NAT handling).
• If ESO still disconnects direct-to-modem: it’s likely ISP path/peering to ESO (or less commonly the SB8200 line quality), not the TP-Link.

3) If the TP-Link is implicated: what to change (in order)​

These are the most common “MMO session drops while everything else stays online” fixes on consumer routers:

1. Update TP-Link firmware (and reboot).
2. Temporarily disable (test one at a time):
   • QoS / Game Accelerator / traffic prioritization
   • DoS protection / SPI firewall
3. Ensure UPnP is enabled (test with it ON).
4. For testing: disable IPv6 on the router (not just Windows).

If you tell me the exact TP-Link model number (AX1800 is a class—e.g., Archer AX21/AX23/etc. and your firmware version, I can point to the exact menu names.

4) If it still happens direct-to-modem: prove “route/peering” vs “line quality”​

Two fast checks:

A) “Change the route” test (diagnostic only)​

Try a VPN just as a test (even Cloudflare WARP is fine). If ESO becomes stable on VPN, that’s strong evidence the normal ISP route/peering to the ESO NA endpoints is the problem.

B) Check the SB8200 signal/event logs​

The SB8200 has a diagnostics page (signal levels + event log). If you see lots of critical entries (timeouts, re-sync events) around the same time, that’s an ISP/line issue. If it’s clean, peering/route becomes more likely.

5) Next data points to post (minimal but decisive)​

1. Result of direct-to-modem test (does it still kick you?.
2. Exact TP-Link model + firmware version.
3. On either PC, run this while ESO is connected and paste output (it may reveal the “second remote address/port” you mentioned):
   

   $pid = (Get-Process eso64).Id
   Get-NetTCPConnection -OwningProcess $pid | Sort-Object RemoteAddress, RemotePort | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State

Once we know whether the issue persists with the TP-Link removed, we can go straight to the correct fix path instead of chasing Windows logs that aren’t firing for this symptom.

 

[Drewsky77]

That’s an important finding: if you can reproduce the same ESO kick-to-login behavior on a different PC on the same home network, it makes a per-PC Windows 11 issue (SPP events, NIC driver quirks, local firewall on one machine, etc.) much less likely. It pushes us toward router/NAT behavior, ISP path/peering, or something ESO-specific.
You’re on an Arris SB8200 modem + TP-Link AX1800 router, and you already identified an ESO endpoint like 198.20.200.23:24506.

1) Quick clarification (helps choose the right branch)​

On the second PC, was it:

• the same ESO account or a different account?
• connected wired to the TP-Link as well?
• disconnecting at the same time as the first PC, or independently?

If it’s two PCs dropping at the same time, that’s almost certainly router/ISP. If it’s independent, it can still be router/ISP/route, but it’s more “session/path” than “whole internet.”

2) Highest-value test now: bypass the TP-Link router (one PC, 10–20 minutes)​

This is still the cleanest way to separate router/NAT vs ISP/route.
Steps (summary):

1. Power off the SB8200.
2. Disconnect SB8200 ↔ TP-Link.
3. Connect PC directly to SB8200 via Ethernet.
4. Power SB8200 back on, wait fully online.
5. Reboot PC (or disable/enable Ethernet).
6. Test ESO until you’d normally get kicked.

Important safety note: when you’re direct-to-modem, keep Windows Firewall ON and don’t do casual browsing—just test the game.

Result interpretation​

• If ESO stops disconnecting direct-to-modem: the TP-Link router is the culprit (firmware/features/NAT handling).
• If ESO still disconnects direct-to-modem: it’s likely ISP path/peering to ESO (or less commonly the SB8200 line quality), not the TP-Link.

3) If the TP-Link is implicated: what to change (in order)​

These are the most common “MMO session drops while everything else stays online” fixes on consumer routers:

1. Update TP-Link firmware (and reboot).
2. Temporarily disable (test one at a time):
   • QoS / Game Accelerator / traffic prioritization
   • DoS protection / SPI firewall
3. Ensure UPnP is enabled (test with it ON).
4. For testing: disable IPv6 on the router (not just Windows).

If you tell me the exact TP-Link model number (AX1800 is a class—e.g., Archer AX21/AX23/etc.) and your firmware version, I can point to the exact menu names.

4) If it still happens direct-to-modem: prove “route/peering” vs “line quality”​

Two fast checks:

A) “Change the route” test (diagnostic only)​

Try a VPN just as a test (even Cloudflare WARP is fine). If ESO becomes stable on VPN, that’s strong evidence the normal ISP route/peering to the ESO NA endpoints is the problem.

B) Check the SB8200 signal/event logs​

The SB8200 has a diagnostics page (signal levels + event log). If you see lots of critical entries (timeouts, re-sync events) around the same time, that’s an ISP/line issue. If it’s clean, peering/route becomes more likely.

5) Next data points to post (minimal but decisive)​

1. Result of direct-to-modem test (does it still kick you?).
2. Exact TP-Link model + firmware version.
3. On either PC, run this while ESO is connected and paste output (it may reveal the “second remote address/port” you mentioned):
   

   $pid = (Get-Process eso64).Id
   Get-NetTCPConnection -OwningProcess $pid |
   Sort-Object RemoteAddress, RemotePort |
   Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State

Once we know whether the issue persists with the TP-Link removed, we can go straight to the correct fix path instead of chasing Windows logs that aren’t firing for this symptom.

 

[Drewsky77]

I was able to reproduce the error while plugged directly into the modem.