So in my last post, I described a method for homing in on who is doing what on the network whilst a machine is shutting down. I expect some, a few, random noise data points represented by PID 0 due to requests being made and then the process being killed before the network activity happens. Or perhaps some last throes of a zombied process finally being cleaned up, maybe.
However, what I’m seeing is that this method of tracing back who is doing what network activity may be broken in Windows. Or, I don’t know this part of Windows as well as I think I do, or I’m missing something. Or when I bonked my head I lost some critical piece of data…
I’m seeing data from customer environments and personally where a large portion of network traffic is billed to IDLE. What gives? Task Offload maybe? Not sure. Something is amiss. This trace below doesn’t have a lot of 0’s but I’m seeing some traces where it’s pid 4 and pid 0 for basically everything and I don’t know why.
Here’s what it looks like:
Above I’ve singled out ARP, it’s a common network function most folks are familiar with. No other reason being picked here, just something to look at.
So we see them, note the “UT Process Name”. Why is there a 0? My machine, ERIS, sent it.
We’ll come back to the 0. Here’s a 4, SYSTEM, great, this I can wrap my head around. TID 1404 in PID 4 did some network activity. It should map to a process in the paired ETL trace collected with WPRUI.
And it does:
Great, but why does 0 happen? How does 0 happen? How did something occur that we can’t account back to the kernel or user mode process space?
Leave a Reply