Force closing UDP port

[pavel.orehov]

Hi,

I am using UDP protocol for communication in my application in C#.
I am using UdpClient class.
The problem is that sometimes the UDP port remains opened/stucked even
if I close the application and restart the computer. Hence, I can't
start this port again and I get an exception.

So I would like to know if there is any way to force closing this port
from the application in case it's already opened.

Thanks,
Pavel

 

[Martin Carpella]

The problem is that sometimes the UDP port remains opened/stucked even
if I close the application and restart the computer. Hence, I can't
start this port again and I get an exception.

A socket can never survive a system restart, so the issue must be
another application using this port or another instance of your
application already started.

Best regards,
Martin

 

[pavel.orehov]

A socket can never survive a system restart, so the issue must be
another application using this port or another instance of your
application already started.

Best regards,
Martin

1. I suppose that it happens because of abnormal flow of my
application.

2. May be there is some external DOS/Windows command which can reset
needed port.

 

[pavel.orehov]

Even restart all network service will be good enough, it should close
all stuck ports.
I have tried to find such a service in services but I didn't find any
that helps.

 

[Ben Voigt]

A socket can never survive a system restart, so the issue must be
another application using this port or another instance of your
application already started.

Yes.

Use "netstat -a -o -p UDP -n" to find out what process has the port open.
Then configure that application to not use your port.

 

[Martin Carpella]

1. I suppose that it happens because of abnormal flow of my
application.

Sorry, cannot elaborate on this issue

2. May be there is some external DOS/Windows command which can reset
needed port.

You could use WMI to find out which process has this port open and try
to kill this process, but this would be a quite "unfriendly" solution to
the problem. But at least it could help you debug by finding the
responsible process. Unfortunately I am not really well-versed in WMI,
so I cannot provide you with a code example.

Best regards,
Martin