[ColinDabritz]

Well huh...

I appreciate the further information, I did try this myself, and the difference is more clear now. The exception object had the StackTrace with the right info, but the debugger highlights the throw; line.

If the Exception.StackTrace has all the juicy details, why on earth not break there?

Yes, I was certainly thinking about the information available in the exception object itself. It's odd that it's set up this way, but I get it makes sense semantically, if other handler code has run, you need to trace things back yourself probably with a debugging step-through session, or turn on 'first chance exceptions' to get the most 'on the ground' information.

To break immediately on an exception before handlers are invoked: http://msdn.microsoft.com/en-us/library/d14azbfh.aspx

In the spirit of learning, Thanks for your contribution!

[Locke1689]

Yup, as I said, the problem is crash dumps. If this only affected debugging it would be a minor annoyance, but it destroys information in client crash dumps which get delivered by Watson, effectively making dumps useless.

Exception filters run before the stack is unrolled, so if you crash your process in an exception filter the stack is preserved.