As you can see, the question I'm relating to yielded a long discussion and a lot of good context. It turns out, I'm running into a similar problem (probably the result of an external .dll also), but I want to know how to *really* avoid/solve it if I can't get rid of the offending .dll. I'm using VS 2008, and I've also checked to make sure the debug option is turned on for the exception assistant.
In my case, the rogue exception is on a backgroundworker--so the program doesn't even end--the thread just goes away and the user assumes all is OK. Not good.
I realize that in a perfect world every exception would be coded for and handled with at try/catch block--but in the real world there are times I need to even force an exception because the cost/benefit of coding for that exception is too high vs a real person intervening.
If it *is* a rogue .dll causing the situation, what can I do? What would be the equivalent of a VB6 'on error goto 0' (the statement that turns off error trapping in VB6)?