[question] How do you determine if a connection was made by the Kernel?

[eabase]

Background:

I'm trying to block some sketchy windows connections originating from the MS surveillance state Kernel.

---

Q1: How does psnet determine that a certain connection is originating from the Kernel?

Q2: Is there a way to get the process - or thread ID's from those connections?

For example,
I have no eff'n idea why my Windows-11 Kernel is connecting to Google Play (play.google.com), as shown above, since I am not using google play at all, nor accessing the GP website or anything else mobile related.

[eabase]

BUMP @psmux

[psmux]

Hey @eabase, great questions! Let me break it down for you.

Q1: How does psnet determine a connection is from the Kernel?

psnet uses the Windows GetExtendedTcpTable / GetExtendedUdpTable APIs which return a dwOwningPid (owning process ID) for every active socket. The logic is straightforward:

• PID 0 is labeled [Kernel] because Windows assigns PID 0 to connections owned by kernel mode network drivers (HTTP.sys, WinHTTP service stack, NDIS miniport drivers, etc.)
• PID 4 is labeled System because that is the actual Windows System process

These are the same PIDs you would see if you ran netstat -b or used Sysinternals TCPView.

Q2: Process or Thread IDs?

The PID is already tracked internally and shown in the Connection Detail popup (press Enter on any connection row). However, I just pushed a change that adds a dedicated PID column directly to the main Connections table so you can see it at a glance without opening the detail view. You can also sort by PID now by pressing the column header key.

As for thread IDs: unfortunately, the Windows network table APIs (MIB_TCPROW_OWNER_PID, MIB_UDPROW_OWNER_PID) only provide the owning process ID, not thread IDs. There is no standard Win32 API that maps a network socket back to a specific thread. Even tools like Wireshark and TCPView have this same limitation.

About those Kernel connections to play.google.com:

This is actually a well known Windows 11 behavior. The Windows Push Notification Service (WNS), Connected User Experiences (DiagTrack), and the Microsoft Store infrastructure all route through kernel mode HTTP.sys, which means they show up as PID 0 / [Kernel]. The play.google.com resolution likely comes from a CDN or ad network endpoint that shares infrastructure, or a pre installed app manifest that references Google Play services for cross platform push notifications.

To investigate further on your end, you could try:

1. Use netsh trace start capture=yes to see which kernel driver initiated the connection
2. Check Windows Event Viewer under Microsoft-Windows-TCPIP/Diagnostic for socket ownership details
3. Use Process Monitor (Sysinternals) filtered to network activity from PID 0/4

Hope this helps! The PID column should make it much easier to spot and investigate these connections going forward.

[psmux]

Update: I just pushed a second change that goes further than just showing PIDs.

psnet now uses the Windows GetOwnerModuleFromTcpEntry / GetOwnerModuleFromUdpEntry APIs to resolve the actual service or module name behind every connection. This means:

• svchost.exe connections now show the real service name instead of just "svchost.exe" (for example: "DNS Client", "DHCP Client", "Windows Push Notifications System Service", "Background Intelligent Transfer Service", etc.)
• The Process column shows the resolved module name highlighted in purple for svchost and system processes
• The Connection Detail popup (press Enter) now has a dedicated Module field
• The detail bar at the bottom shows process_name (module_name) format

For PID 0 [Kernel] connections specifically: the Windows kernel does not expose which internal driver owns those sockets through standard APIs (GetOwnerModuleFromTcpEntry returns ERROR_NOT_FOUND for PID 0). This is a Windows limitation that even Sysinternals TCPView shares. However, many connections that appear to come from the kernel are actually owned by svchost.exe services, and those are now properly identified with their real service names.

This should make it much easier to track down exactly which Windows service is phoning home to unexpected addresses.

[psmux]

BUMP @psmux

Keep me posted how it went with the new commit.

cargo install --git https://github.com/psmux/psnet