To be 100% sure what the problem is, crack out windbg with the SOS extension for .Net. You can use ADPlus to take a memory dump of the .Net process in question, and then load the dump file into windbg. The SOS debugger extension is used for debugging .Net memory dumps. Using !dumpheap -stat will show you all instances of objects on the heap. Given an instance handle, using !gcroot will tell you which thread is keeping the instance alive. Using !clrstack for that thread will show you the stack for that thread, pin pointing the exact code. These commands are only the tip of the iceberg though, check out Tess Fernandez's blog at http://blogs.msdn.com/b/tess/[^] for help on using windbg for memory leak debugging in .Net.

When developing apps that use worker threads which like to report back a status, a good technique I have used on projects is to set up a data structure (class or struct) that holds member variables for all the "stats" that the threads must update. Each thread updates the fields in the class/struct, without caring who may be "listening". For dialogs that like to report the status of these threads (i.e. using progress bars, updating text boxes etc), they query the class / struct member variables. This way the relationship is decoupled and state-free. This is a technique we used a lot in the Win32 programming model, and it works just as well in .Net.

In addition to others mentioned I also found the Wrox book Professional C++ and C++ Coding Standards by Herb Stutter and Andrei Alexandrescu helpful. If you want to apply to Windows, you can't go past Jeff Richter's Programming Windows via C/C++.

Jeff Richter's book CLR via C# has an excellent chapter devoted to Exception management for the runtime and C#. It goes into great depth for the following topics: - Preferring try / finally blocks for managing exceptions (instead of blindly catching everything that comes your way) - Setting Exception policy handlers for the main thread and worker threads These two strategies allow you centrally manage unhandled exceptions for all threads while still allowing you to have precise control over the exceptions that you chose to handle. I use his strategies as a consultant/contractor for all my .Net projects. It's amazing the responses you get from dev's when you explain to them they should use try / finally liberally and not try / catch !!! Like Richter's work for native code, his runtime work goes into great detail and is very helpful.