I was reading up on ETW, and discovered the TCPView tool. Having recently worked with the joys of ip_conntrack on Linux hosts with iptables and bad PHP frameworks leaving TCP sessions in TIME_WAIT, this was a nice find for Windows.
But in reviewing this article, its curious that Microsoft doesn't demonstrate the use of native OS tools to triage a simple port binding issue. So here's a quick example to help you find what's listening on TCP 80.
C:\> netstat -p TCP -on | find ":80 "
TCP 172.16.37.100:80 18.104.22.168:443 ESTABLISHED 320
This shows us a list of TCP ports with the numeric port value and the PID.
C:\> tasklist /FI "PID eq 320"
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
w3wp.exe 320 Services 0 99,344 K
Pass the PID in a predicate filter to tasklist, and we find the process name. Since it's an IIS worker process, we must go a step further to identify the Application Pool:
C:\> %windir%\system32\inetsrv\appcmd.exe list wp
WP "320" (applicationPool:WsusPool)
Another great feature of netstat is it's statistics feature, which a peer pointed out to me:
C:> netstat -s
It's left as an exercise to the reader to peruse the value that single command can have in troubleshooting down the stack before you worry about data link and the physical layer. You've already swapped out that crossover cable for a regular patch, right?