How to read a shutdown trace from NETSH and WPRUI to home in on what PID is doing what network traffic at shutdown

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:

ARP packets during shutdown

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.

another view of PID

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:

stuff be stuffing

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?

0 and 0

Be the first to comment

Leave a Reply