Just when you think it's safe to go back in the water
Microsoft development libraries and tools have been around a long time and it's easy to think that all the kinks have been worked out. If weird stuff happens it's got to be in my code…right? Wrong.
I spent several days trying to figure out why, when I stepped (F10) over an instruction…I lost my thread. I thought of everything that could go wrong: GC, aborted thread, ThreadPool starvation, etc… I tried a lot of stuff.
A word of debugging advice, whenever you find yourself in a messy situation, try to find the simplest setup that produces the problem. I stripped my code down to:
public partial class frmMyForm : Form
private void frmFonBook_Shown(object sender, EventArgs eArgs)
ThreadPool.QueueUserWorkItem(new WaitCallback(_DoSomething), this);
static void _DoSomething(Object state)
frmMyForm frmObject = state as frmMyForm;
if (frmObject != null )
Eventually I hit on the right search terms and came up with this link. There are some other links in the post that explain things in more detail here and here. It's a crazy world but the IDE was actually the problem NOT my code.
Basically to get around this probem open VS2005, select Tools->Options->Debugging->General and then disable the 'Enable property evaluation and other implicit function calls' checkbox.
So here are some search terms that I hope will make someone else's life easier:
collected thread object