The behavior described (system process related to TCP/IP suddenly consuming resources and suspicion of malware) matches known cases where networking components or related counters misreport usage, or where a networking stack issue causes abnormal resource consumption.
From the provided information, the closest documented pattern is:
- Networking/TCPIP-related components can hit bugs that cause hangs, high resource usage, or misleading counters (for example, Winsock/TCPIP race conditions and GPU/memory counters reporting incorrect values).
- On affected Windows 10/11 systems, Task Manager’s per-process GPU/memory counters can show incorrect values, while the actual usage (seen in the Performance tab or with Windows Performance Recorder/Analyzer) is normal.
To narrow down whether this is a real load or just a reporting issue, and whether it is likely malware or a system bug, follow these steps:
- Validate whether GPU usage is real or misreported
- Open Task Manager → Performance → GPU and watch the Dedicated GPU memory and 3D/Copy/Video Decode graphs while the “TCP/IP Application services” process shows 100% GPU in the Processes → GPU column.
- If the Performance pane shows normal/low GPU usage while the process list shows 100%, this matches the known counter issue. In that case, rely on the Performance pane, WPR, or WPA for accurate GPU usage instead of the per-process GPU column.
- If both the Performance pane and the process list show sustained high GPU usage, treat it as real load and continue with the next steps.
- Check for TCP/IP or Winsock-related hangs or leaks
- Open an elevated PowerShell window and run:
Get-NetTCPConnection | Group-Object -Property State, OwningProcess | \
Select-Object Count, Name, @{Name="ProcessName";Expression={(Get-Process -PID ($_.Name.Split(',')[-1].Trim(' '))).Name}}, Group | \
Sort-Object Count -Descending
This helps identify if any process is leaking TCP connections (for example, many connections stuck in CLOSE_WAIT or BOUND states).
- If a non-system process is responsible (for example, a browser, game, or third‑party app), close or uninstall that app and see if the GPU spike stops.
- Look for handle/port leaks that can indicate a faulty or malicious app
- Open Task Manager → Details.
- Add the Handles column.
- Sort by Handles and look for a process (other than core system processes like System, lsass.exe, sqlservr.exe) with an unusually high and growing handle count (often >3000).
- If such a process exists, end that process and see whether the GPU spike and any networking issues stop. If they do, uninstall or update that application.
- Check for known TCP/IP driver issues
- Ensure Windows is fully updated, as several TCP/IP bugs (including race conditions in tcpip.sys and WFP/Winsock issues that cause hangs and resource problems) have been fixed via updates.
- If the issue started immediately after a Windows update or driver change, check Settings → Windows Update → Update history to see what changed around that time.
- Malware suspicion and next steps
- Because the symptoms can also be caused by malware that hooks into networking, continue to:
- Run a full scan with Windows Security and a reputable antimalware tool.
- If scans are clean but symptoms persist, consider an in‑place repair or reset of Windows while keeping personal files, as documented in the Windows reset guidance in the context.
If, after verifying with the Performance pane/WPR/WPA, the GPU usage is only misreported and the system otherwise behaves normally (no overheating, no lag, no crashes), this is likely the known GPU counter issue rather than a virus. In that case, use the Performance pane or WPR/WPA to monitor GPU usage instead of relying on the per‑process GPU column.
References: