先看这个例子，点下这个按钮，你的浏览器一定会崩溃掉。至少在微软修复这个BUG之前会崩溃掉。
经过测试的浏览器有：IE、Chrome、FireFox，其他浏览器，不保证100%崩溃。
重现这个BUG
新建一个SL项目SilverlightApplication1，把MainPage.xaml内容修改为
<UserControl
x:Class="SilverlightApplication1.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:SilverlightApplication1"
>
<local:MainPage />
</UserControl>
然后运行。如果你是直接在VS里操作，你会发现VS也一块崩溃了。
我们来分析这个项目。全部都是默认生成的框架，本身没有任何问题。我们只是在MainPage的UserControl里，把自己加入到自己的Context里面。按照逻辑，这个页面会无限的构造下去。这样就导致了“StackOverflowException”。
通常情况下，用户代码的异常都会被 Application_UnhandledException 捕获，并报告给DOM。但是这个异常是在mscorlib.dll产生的，并且（可能）属于 non-CLSCompliant exceptions 导致用户代码不能够捕获到。注：限于本人知识有限，这个假设并不一定正确。
在WPF里，也有类似的BUG
大家可以自行修改代码让WPF也崩溃一次。
现在来看WPF里的另外一个BUG
新建一个任意（非asp.net）项目，并且添加Microsoft.ReportViewer.Common、Microsoft.ReportViewer.WinForms、System.Windows.Forms 和 PresentationFramework 程序集。
Program.cs写入如下代码：
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
System.Windows.Markup.XamlWriter.Save(new Microsoft.Reporting.WinForms.ReportViewer());
}
}
}
运行后一样的抛出“StackOverflowException”。
如果加上try...catch...语句，效果是一样的，无法捕获到异常。只会在Console得到
Process is terminated due to StackOverflowException.
如果说这是non-CLSCompliant exceptions那么我们可以配置开启legacyCorruptedStateExceptionsPolicy。
<?xml version="1.0"?>
<configuration>
<runtime>
<legacyCorruptedStateExceptionsPolicy enabled="true"/>
</runtime>
</configuration>
开启后一样会“StackOverflowException”。
至于这是什么状况导致开启了 legacyCorruptedStateExceptionsPolicy 也无法捕获到这个异常，希望有朋友能够帮助大家解答。
或者，这本身就是微软 .NET 框架的 BUG ？
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
UPDATE : 感谢朋友们的热情讨论。
对于这个现象，不管说这是程序的BUG还是说这是runtime的BUG，至少这个现象对于使用体验来说是很不利的。谁都不希望使用的时候进程直接崩溃掉，丢失了所有未保存的作业，而不给出任何友好的提示。
但正如 #19 yyww 所说：目前能做到的，只是让你打个日志记录一下。并没有办法改变崩溃的局面。
#21楼 愚溪 的想法很不错。如果说CLR能够在 StackOverflow 和 OutOfMemory 的时候，自动退栈，直到出现catch语句，给开发者一个处理错误的机会，或许程序还能够继续执行。