I recently responded to this "bug" on the MSDN Product Feedback Center, but I thought it would be valuable for more people than just "SecurityException" to get this explanation. The situation is this - Visual Studio 2005 Beta 2 stopped the debuggee and showed an exception dialog when an exception was thrown from an asynchronously-called delegate. Why is this? When it's run outside the debugger, everything works fine.

Well, the simple answer is that everything is still fine. And even better, let's all repeat together: "it's not a bug, it's a feature." :0)

The thing that has changed since the last version of Visual Studio is that, by default, we will break execution and show exception information in cases where there isn't necessarily anything bad going on. The most common of these is something we call a "user-unhandled" exception.

To fully explain how this works I'll first have to explain a new feature called Just My Code. We use a heuristic to determine if a given module (see Debug->Windows->Modules Window) is "user code" or not - if we have symbols (a .PDB file) for the module and it is unoptimized then it's user code. If it is determined to be user code, we'll step through it, hit breakpoints in it, etc. Otherwise we won't. This makes it possible, for example, to step between event handlers in a WinForms app, but it will prevent you from debugging the framework (you'll have to turn off the feature for that: Tools->Options->Debugging->General->Enable Just My Code).

With that in mind, let's talk about "user-unhandled" exceptions. If an exception is thrown and passes through user frames but is then not caught by user code, it is considered "user-unhandled." In SecurityException's specific case it was caught by the .NET framework infrastructure around asynchronous delegate calls. In some cases this is a bad thing, in others it isn't. So the debugger will tell you about it, but it behaves like a first-chance exception - press F5 and your program continues on its merry way. Or you can click "edit code" in the Exception Assistant (or unwind via the callstack - both of these reset the program to its state just before the call the caused the exception) and do some Edit and Continue to solve the problem. The choice is yours.

Of course, if you really don't want to hear about these events, you can go to Debug->Exceptions and deselect the "user-unhandled" column.

Hopefully you find this feature useful. Let me know what you think!