Loose threads...

I have been working on one particular app (a Win32 service) for some time now, and as a regular course of work would frequently run through this sequence:

1. Code changes
2. Build project
3. Stop service in test environment
4. Copy assemblies from build folder to test environment

I’ve done this countless times, but was frequently annoyed at how long step #3 took (stopping the service).   The service itself, as a process would stop reasonably fast, but sure enough, assemblies would be “locked – in use” for 20 seconds or so longer, evidencing that not all threads of the service were completely stopped yet.  I had a Stop routine for the app/service which ran through the various modules, waiting for each to stop, but apparently something was missed.  And unfortunately the app was fairly large & complex, so there were many places where a thread could have been left running…
This thought has teased me for some time, but any attempt to find some loose end proved futile.  Everything I could find looked good & tight, with no evidence of what was left hanging.
Then the thought occurred to me to put a breakpoint on the last active line of the app/service and stop there (in debug mode).
Once I had the app stopped at that point in debug mode, I popped open the “Threads” window, and voila! The guilty party was quickly found as a thread still running when it should not have.  In this case, the problem was an object that was not property disposed, left hanging in memory, including an async process thread it “owned”.  Once that was fixed, the problem of “slow stops” for the service went away.

Photo by Jon Ross