Tracking down a memory leak

Hello all;

I am trying to track down a memory leak in my application. I looked all over my code for the usual suspects, and I think I took care of the housekeeping. The application is running on a Windows host. Using the task manager, I notice that when I start my app as a service, it has 4 threads open. Every time I connect to the application, new threads are created (so far that seems normal). When I log off, some of the threads are closed (as expected), but for every session, one thread remains. One connexion, 5 therads. 2 connexions, 6 threads once all sessions are closed, and so on. At some point, the application becomes unresponsive even if the memory usage remains way below anything that I would be alarmed with. (around 25 MB when it becomes unresponsive. it uses 10MB roughly when restarted and idle)

Obviously, I missed something in my housekeeping. My application does not explicitly start threads, so these threads are managed at the framework level. Is there a way to get more information on what these threads are? I would like to understand what are the orphan threads remaining after the session is closed. I suppose that if I know what the thread does, it will point me to some housekeping that I need to do and missed so far.

Thanks in advance for any hint or source of inspiration.

I figured it out. It took 20 code reviews, and only one glass of red wine… note to self: less reviews, more wine.

The story is this: I am using ADODB to connect to a SQL Server backend. I have one connexion per session. In my close event, I was setting the connexion object to nil, but I forgot to close it first. So, for anyone still using ADODB (the preferred method documented by MS is now ODBC) remember to call the close method of the connexion first, and to set it to nil next. The added benefit is that if there were still some open recordset, they will also all be closed at the same time.