Does Windows take care of closing sockets when processes exit?

Question

I've read up this question about Linux, Can a port be bound when the process has terminated?
Linux appears to clean up after processes exiting, and leaving open sockets. I was wondering if there's any specification about how this works on Windows. Does the OS consistently take care of closing sockets for processes which exit without closing them?

Answer 1

On both Windows and Unixen, when a process exits the kernel closes all open handles.

Windows NT

Terminating a Process – MSDN

Terminating a process has the following results:

• [...]
• Any resources allocated by the process are freed.
• All kernel objects are closed.
• [...]

While open handles to kernel objects are closed automatically when a process terminates, the objects themselves exist until all open handles to them are closed. Therefore, an object will remain valid after a process that is using it terminates if another process has an open handle to it.

ExitProcess function – MSDN

Exiting a process causes the following:

• [...]
• All of the object handles opened by the process are closed.
• [...]

Linux

exit(3) – Linux Programmer's Manual (libc functions)

All open stdio(3) streams are flushed and closed.

_exit(2) – Linux Programmer's Manual (kernel syscalls)

The function _exit() terminates the calling process "immediately". Any open file descriptors belonging to the process are closed; any children of the process are inherited by process 1, init, and the process's parent is sent a SIGCHLD signal.

---

Note that on both operating systems,

1. Sockets are just one type of file descriptors (fd's) / kernel objects, so the above applies equally to files and sockets.

2. File descriptions on Unix, as well as object handles kernel objects on Windows, can be owned by multiple processes – they their handles can be inherited by child processes and even passed around using special IPC functions.

3. A file or socket is only closed when all fd's pointing to it are destroyed.

Answer 2

On Windows, a socket is a link between a communications endpoint and a process. This is why, when you duplicate a socket, you wind up with two sockets but only one endpoint. This is why you can't pass a socket from one process to another without creating a new socket in the other process.

If the process ceases to exist, its sockets necessarily cease to exist. There is no concept of a socket without a process to hold it. This is why even Windows kernel drivers that wish to create sockets at kernel level must specify a process to own the socket or call the function from a process context that can own the socket. (Or they can manipulate the endpoints directly without using sockets.)

Your question seems to really be not about sockets but about the communication endpoints themselves. A socket has a reference to its communication endpoint. When the socket goes away, the reference count drops. If it hits zero, it will be removed as soon as that is permissible given the requirements of the communication protocol that endpoint is associated with. TCP has a TIME_WAIT state during which the endpoint must be kept around to handle any "leftover" packets.

Answer 3

Yes it does. It has been this way sense windows 3.1 95 98 XP (At least I know for sure since XP).