Windows Explored

Among the various types of operations Process Monitor traces, TCP/UDP activity is often overlooked. If you want to examine packets, Process Monitor is not going to do it for you. But it can sometimes present some important clues to a problem and point you in the right direction.

In the case here, our user was not able to get our in-house chat program to go online. You can usually force this by selecting the “List” button, but after several seconds of “Loading…” it would go back to offline. In hopes of finding something revealing, I opened Process Monitor from our lab and set a filter for the executable of the chat program. There were only a dozen operations but the ones that stood out were the last 5 UDP Send operations.

Our chat program connects to its server service installed on the local print server of each office. In trace above I saw that the user’s system is going to an IP located on a completely different subnet than the print servers, 10.78.X.X. The send operation should be going to an IP of 10.63.X.X (or xxx-ps1). Here is the same trace performed from my chat when clicking the “List” button, and you can see traffic going to xxx-ps1:

So why was the chat application trying to send to 10.78. and not getting anywhere? The answer to this was a second NIC installed in the user’s system, Local Area Connection 2. This second NIC setup is unique for this one user. It needs to point to our IP phone server and also contains an IP in 10.78.X.X range. The user’s system was recently replaced and when the second NIC was installed the binding order changed to the top of the list. To resolve, we changed the binding order of the NICs and made Local Area Connection first in the binding order.