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]

Reproducing the same ESO kick-to-login on a second PC on the same network is a big clue: it makes this very unlikely to be caused by Windows SPP events, a single NIC driver, or something local to one PC. It strongly points to network path / router behavior / ISP routing instead.

1) Quick clarifiers (so we pick the right branch)​

On the 2nd PC test, please tell me:
1) Was it wired to the TP-Link (not Wi‑Fi)?
2) Same ESO account or a different account?
3) Did both PCs disconnect at the same time, or independently?
If both PCs drop at the same time, that’s almost certainly router/ISP. If independently, it can still be router/ISP/route, but it’s more session/path-specific.

---

2) Most decisive test: bypass the TP‑Link router (10–20 minutes)​

Since you’re using Arris SB8200 + TP-Link AX1800 and already saw an ESO endpoint like 198.20.200.23:24506, the fastest “yes/no” is still to remove the TP-Link from the equation.
Steps

1. Power off the SB8200.
2. Disconnect SB8200 ↔ TP-Link.
3. Plug the PC directly into the SB8200 via Ethernet.
4. Power on SB8200, wait fully online.
5. Reboot PC (so it pulls the public IP).
6. Launch ESO and play until you’d normally get kicked.

Safety: keep Windows Firewall ON; don’t casually browse while direct-to-modem.
What the result means

• No disconnects direct-to-modem → TP-Link settings/firmware/NAT feature is the likely culprit.
• Still disconnects direct-to-modem → more likely ISP routing/peering to ESO (or SB8200 line quality).

---

3) If it points to the TP-Link: top settings to test (one at a time)​

These are the highest-yield toggles for “game drops but internet looks fine”:
1) Update TP-Link firmware, reboot router
2) Temporarily disable (test):

• QoS / Game Accelerator / Traffic Prioritization
• DoS protection / SPI firewall
  3) Enable UPnP (test with it ON)
  4) Temporarily disable IPv6 on the router

If you post the exact router model (AX1800 is a class—e.g., Archer AX21/AX23/etc. + firmware version, I’ll tell you exactly where those settings are in the UI.

---

4) If it still happens direct-to-modem: confirm “route/peering” quickly​

Two strong diagnostics:

• Try a VPN as a test (Cloudflare WARP is fine). If ESO becomes stable, that strongly suggests ISP route/peering is the issue (the VPN changes your path).
• Pull the SB8200 signal levels + event log around the disconnect times (power/SNR and correctables/uncorrectables). If you see lots of errors/timeouts, that’s a line-quality/ISP issue.

---

5) Minimal outputs that will let me call the next move​

When you can, please reply with:
1) Result of the direct-to-modem test (still kicked: yes/no, and roughly how long you tested).
2) Exact TP-Link model + firmware version.
3) Whether the two PCs dropped simultaneously or not.
Once we have that, we’ll know whether to focus on TP-Link configuration/firmware or on ISP/peering escalation with good evidence.

 

[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.

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

 

[ChatGPT]

That result is huge: if ESO still kicks you to login while your PC is plugged directly into the SB8200 (no TP-Link in the path), then we can stop spending time on TP-Link QoS/UPnP/NAT theories. At that point the likely causes narrow to:
1) ISP path/peering/routing to ESO (common), or
2) DOCSIS signal/line impairment on the SB8200 (T3/T4 timeouts, uncorrectables, upstream noise), or
3) something ESO/server-side (less common, but possible).
This also matches what you saw earlier: the disconnect can happen while general ICMP pings stay clean (gateway + 1.1.1.1), which points away from a “full internet drop” and toward a more specific session/path issue.

Step 1 (fastest proof): “Change the route” test using a VPN (diagnostic only)​

Even a short test is useful:

• Install Cloudflare WARP or use any reputable VPN.
• Connect VPN.
• Play ESO until you’d normally disconnect.

Interpretation

• Stable on VPN: extremely strong evidence of an ISP routing/peering issue to ESO (your traffic takes a different path).
• Still disconnects on VPN: then it’s less likely peering and we focus harder on SB8200 signal/line or ESO itself.

Step 2: Check the SB8200 signal levels + event log (this is what your ISP will care about)​

While connected directly to the modem (or even normally), browse to the modem status page (commonly):

• [url]http://192.168.100.1[/url]

Grab screenshots (or copy values) for:

• Downstream: Power levels + SNR
• Upstream: Power levels
• Uncorrectables/Correctables counts (if shown)
• Event Log (look for T3/T4 timeouts, SYNC failures, etc.

Also note the exact local time of a disconnect so you can match it to the modem log.
If you post those pages here, I can tell you if the levels look suspicious enough to involve your ISP.

Step 3: Confirm which ESO endpoint(s) you’re actually using when it drops​

You already identified at least one ESO endpoint (example: 198.20.200.23:24506).
Now we need the full list so we don’t chase the wrong one.
Run while logged into ESO:

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

Paste the output (you can redact local IP if you want; keep remote IP/ports).

Step 4 (if needed): packet capture to see if it’s a TCP reset / timeout​

If VPN testing is inconclusive and modem levels look fine, the most definitive next step is a short capture around the disconnect using:

• Wireshark, or
• Windows built-in pktmon (more awkward but works)

What we’re looking for: does the connection get a TCP RST/FIN, or does the client just stop receiving and time out?

---

One clarifying question​

When you reproduced the disconnect direct-to-modem, did you also run the same two pings (router/gateway won’t apply, but at least 1.1.1.1 and 8.8.8.8)—and were they still perfectly clean at the exact moment of the kick?
If you do the VPN test + grab the SB8200 signal/log pages, we can usually conclude “ISP route” vs “ISP line quality” pretty decisively and you’ll have something concrete to bring to the ISP or ESO support.

 

[ChatGPT]

If you can still reproduce the ESO kick while connected directly to the SB8200 modem, that essentially clears the TP‑Link router as the primary cause. At that point the likely buckets are:

• ISP path/peering/routing to ESO (NA megaserver), or
• DOCSIS line quality / modem signal issues (brief impairment that won’t always show up as obvious “internet down”), or
• ESO/server-side behavior affecting your ISP/path specifically

You already identified at least one ESO endpoint as 198.20.200.23:24506.

Step 1 (quick yes/no): does changing the route fix it?​

This is the fastest way to prove “ISP route/peering” without waiting on support.

Test with a VPN (diagnostic)​

• Install Cloudflare WARP (or any reputable VPN) and play ESO long enough to normally get kicked.
• If ESO becomes stable on VPN: that strongly suggests your normal ISP route/peering to ESO is the problem (VPN forces a different path).
• If ESO still kicks on VPN: more likely a line quality / modem impairment, or ESO itself.

(You don’t have to keep using a VPN forever—this is just to isolate the cause.

Step 2: pull SB8200 signal levels + event log (this is what the ISP will act on)​

On the SB8200, grab screenshots (or copy/paste) of:
1) Downstream bonded channels (Power, SNR, Correctables/Uncorrectables)
2) Upstream bonded channels (Power)
3) Event Log (especially entries around the exact disconnect times)
If you post those here, I can tell you if the numbers look “clean” or if there’s a signal/impairment problem you should push your ISP to fix.

Step 3: run a better “while gaming” stability log (timestamps matter)​

Earlier you proved you can be kicked while pings look fine. That can happen if the issue is upstream congestion/impairment or something affecting game traffic more than ICMP.
While playing, run this (PowerShell) to log packet loss to a file:

while ($true) { $ts=(Get-Date).ToString("yyyy-MM-dd HH:mm:ss") try { $r = Test-Connection 1.1.1.1 -Count 1 -ErrorAction Stop; "$ts OK $($r.ResponseTime)ms" } catch { "$ts TIMEOUT" } Start-Sleep -Seconds 1
} | Out-File "$env:USERPROFILE\Desktop\ping_1.1.1.1.txt" -Append

If you can also identify your first ISP hop (the 2nd hop in traceroute earlier, e.g. the cable modem CMTS/gateway) you can run the same log to that IP as well.

Step 4 (optional but definitive): capture what happens to the ESO connection​

If the VPN test doesn’t clearly answer it, the next “hard proof” is a short Wireshark capture during a disconnect:

• Capture on your active Ethernet adapter
• Apply display filter: ip.addr == 198.20.200.23
• When you get kicked, look for:
  • TCP RST (reset) packets, or
  • lots of retransmissions / “TCP Previous segment not captured”
    This can tell us whether the connection is being reset remotely vs dying due to loss.

Two quick questions​

1) When you tested direct-to-modem, about how long did you play before it kicked you? (5 min / 30 min / etc.
2) Can you post the SB8200 downstream/upstream tables + event log screenshots?
Once we see the SB8200 levels and whether a VPN stabilizes ESO, we’ll know whether to focus on ISP line quality (most common with DOCSIS intermittent issues) or ISP peering/routing to ESO.

 

[datawizard0103]

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?

No, Wi-Fi roaming doesn’t matter on a wired connection. The missing piece here is IPv6. On Windows 11 it can cause brief network drops that only show up in online games. Disable IPv6 on your Ethernet adapter and test ESO again. Also install the latest network driver directly from your motherboard or system manufacturer, not Windows Update. This combo fixes silent MMO disconnects more often than anything else I see in real-world cases.