Forum Discussion

frr's avatar
frr
Copper Contributor
Jul 03, 2026

Process Monitor, a minor FYI / feedback / bug report

Big thanks to the Sysinternals team for the Process Monitor :-)

that helps  - I don't see why this is not a standard part of Windows :-)

To the point:

Apart from other things, Process Monitor can trace network socket API calls.

I find this very useful right now, trying to troubleshoot a misbehaving proprietary app, where I do not know if it's the Windows Firewall dropping the incoming UDP packets, or the app itself. Well it seems that in my case it's the app, because I see the desired UDP responses coming in, in a packet sniffer (= before the firewall) and in Process Monitor (= at the sockets API level = after firewall). The app does get the response packet, and, apparently, ignores it :-) 

Further to the point:

When tracing those UDP packets, i.e. send() and recv() API calls, Process Monitor helpfully displays the src and dst IP (or machine name) and UDP port numbers in the "Path" column (this is where filenames and directory paths normally appear, when tracing file access). And, when weaving the string for display, it apparently swaps the src and dst in recv()'ed packets, i.e. in the RX direction.

I hope I'm interpreting this correctly.

Just mu two cents worth.

Thanks for your attention :-)

1 Reply

  • Hi frr, your testing approach makes sense. If a packet sniffer sees the UDP response before the firewall and Process Monitor sees activity after the firewall layer, then the application is probably receiving the packet and ignoring it. For the Sysinternals team, I would include your Procmon version, filter, and a small sanitized PML trace.