What can cause section handle leaks?

Quoting Mark Russinovich's Inside Windows 2000 (what is now called Windows Internals),

The section object, which the Win32 subsystem calls a file mapping object, represents a block of memory that two or more processes can share.

So, it's a memory mapped file. They'd leak if you created a memory mapped file and failed to close it. Pretty hard to be much more specific.

It turns out that the problem was in a low-level function that counts the number of threads of the current process. This function used the

CreateToolhelp32Snapshot

API function which returns a handle, which was not closed properly. I am not sure why this produces a section handle leak though.

A memory mapped file not associated with a file handle can be used for IPC (communication between process). If you do not use them directly, perhaps one of your unit or component is doing some IPC communication. It is very likely that you use a component to connect to another process, and do not release it as requested.

First action to be taken is to track for any memory leak (using FastMM4 debug mode), and you'll certainly find some un-released objects in your code.

Since handles are commonly allocated by objects, from my experiment, resolving all memory leaks will resolve handle leaks.

If you do not have any memory leak, there is some CreateFileMapping() calls to check for a corresponding CloseHandle() in all your source code (including third-party source).