Already dead process is continuing to eat net traffic

Question

I'm using Windows 7, Ruby 1.9.2, SciTE, Outpost Pro 2009 and NetBalancer.

Wrinting Ruby programs in SciTE I press Ctrl+Break to kill them. This way is designed to be easy, quick and reliable. But now I wrote a kind of program I never wrote before and found a problem.

Program crowls a website in 10 threads (Thread.new) with open-uri. Each thread downloads one small file. Some urls have Timeout::Error.
When I press Ctrl+Break, process ruby.exe dies (I can see it in Task Manager also) and SciTE is ready for the next F5. Outpost also doesn't show me any net activity.
BUT! The NetBalancer's icon in tray shows, that my net is maximally loaded – 512kbps. When I open NetBalancer I see green line, showing net load, but there is no traffic-eating process in list, so I don't know what should I kill to stop it.
And when I do netstat -o, I see this:

  TCP    192.168.1.2:53629      server2:http           FIN_WAIT_1      916
  TCP    192.168.1.2:53630      server2:http           FIN_WAIT_2      916
  TCP    192.168.1.2:53631      server2:http           FIN_WAIT_2      916
  TCP    192.168.1.2:53632      server2:http           FIN_WAIT_2      916
  TCP    192.168.1.2:53648      server2:http           FIN_WAIT_2      916
  TCP    192.168.1.2:53664      server2:http           FIN_WAIT_2      916
  TCP    192.168.1.2:53667      server2:http           FIN_WAIT_2      916
  TCP    192.168.1.2:53676      server2:http           FIN_WAIT_2      916

Seems like I have just to use taskkill, but:

C:\Windows\system32>taskkill /PID 916
Ошибка: Не удается найти процесс "916".

(Translation: Can't find process "916")

Invisible process continues to eat all my net channel for several minutes and then stops. Connections in netstat also dissapear. But I even don't understand how, why and when does it stop, because the full downloading task should last near an hour. So it dies spontaneously?
Anyway I want to have a way to kill this invisible net-eaters.

Answer 1

When the process exits, Windows requests the server to close the TCP connection by sending a FIN packet. However, since your connection is being used at 100%, the FIN packet takes some time to reach the server. During that time, the server doesn't know about the process death and sends even more data to you. The FIN-WAIT state means your computer sent a FIN packet and is waiting for an acknowledging FIN+ACK.

The process is already dead; you're seeing its PID because the PID is stored along with other TCP connection parameters, and the connection hasn't been closed yet.