OS; resources automatically clean up

Question

From this answer: When is a C++ terminate handler the Right Thing(TM)?

It would be nice to have a list of resources that 'are' and 'are not' automatically cleaned up by the OS when an application quits. In your answer it would be nice if you can specify the OS/resource and preferably a link to some documentaiton (if appropriate).

The obvious one:

Memory: Yes automatically cleaned up. Question. Are there any exceptions?

Answer 1

Any exception is a bug - applications can and do crash and do contain leaks. An OS needs to be reliable and not exhaust resources even in the face of poorly written applications. This also applies to non-OS resources. Services that hand out resources to processes need to free those resources when the process exits. If they don't it is a bug that needs to be fixed.

If you're looking for program artifacts which can persist beyond process exit, on Windows you have at least:

• Registry keys that are created without REG_OPTION_VOLATILE
• Files created without FILE_FLAG_DELETE_ON_CLOSE
• Event log entries
• Paper that was used for print jobs

Answer 2

In Windows, just about anything you can get handle to should be in fact be managed by the OS - that's why you only get a handle. This includes, but is not limited tom the following (list copied from MSDN docs for CloseHandle() API):

Communications device 
Console input 
Console screen buffer 
Event 
File 
File mapping 
Job 
Mailslot 
Mutex 
Named pipe 
Process 
Semaphore 
Socket 
Thread 
Token 

All of these should be recovered by the OS when an application closes, though possibly not immediately, depending on their use by other processes.

Other operating systems work in the same way. It's hard to an imagine an OS worth its name (I exclude embedded systems etc.) where this is not the case - resource management is the #1 raison d'etre for an operating system.

Answer 3

There are some obscure resources that Windows does not clean up when an app crashes or exits without explicitly releasing them, mostly because the OS doesn't know if they're important to leave around or not.

1. Temporary files -- as others have mentioned.
2. Globally registered WNDCLASSes ("No window classes registered by a DLL are unregistered when the DLL is unloaded. A DLL must explicitly unregister its classes when it is unloaded." MSDN) If your global window class also has a class DC, then that DC will leak as well.
3. Global ATOMs (a relatively limited resource).
4. Window message IDs created with RegisterWindowMessage. These are designed to leak, since there's no UnregisterWindowMessage.
5. Semaphores and Events aren't technically leaked, but when the owning application goes away without signalling them, then other processes can hang. This is not true for a Mutex. If the owning application goes away, other processes waiting on that Mutex are released.
6. There may be some residual weirdness on Windows XP and earlier if you don't unregister a hot key before exiting. Other applications may be unable to register the same hot key.
7. On Windows XP and earlier, it's not uncommon to have a zombie console window live on after a process crashes. (Specifically, a GUI application that also creates a console window.) It shows up on the task bar. All you can do is minimize, restore, or move the window.
8. Buggy drivers can be aggravated by apps that don't explicitly release resources when they exit. Non-paged pool leaks are fairly common.
9. Data copied to the clipboard. I guess that doesn't really count because it's owned by the OS at that point, not the application that put it there.
10. Globally installed hooks aren't unloaded when the installing process crashes before removing the hook.

Answer 4

Temporary files is a good example of something that will not be cleaned up - the handle is released but the file isn't deleted