最近做了个net.tcp协议的WCF双工服务，宿主程序（Console或者WPF）老是自动退出。不知道什么原因，希望各位能给分析分析。
------解决思路----------------------
如果程序中出了异常不会导致宿主程序崩溃
这个说法很有问题
既然没有出任何异常,那它自己为什么崩溃了
只能说,你没有能够测试出到底什么异常使他崩溃
------解决思路----------------------
还有在回调的时候，如果恰逢客户端掉线会导致宿主程序（控制台Console）异常退出
这是必然的,客户端掉线了,socket就指向空引用了,你继续对它进行操作必然是报错了
而报错了又不处理,不就崩溃了
------解决思路----------------------
常见的导至整个程序自动退出的原因主要是WCF内部 连接或接收据出现了异常。双工情况下最常见，特别是服务端在发送给客户端数据时，客户端突然掉线此时WCF内部发送取不到这个这个客户端对像了。出现了异常导至整个控制台自动退出了，这种异常不容易捕获。我们也在用WCF双工模式，跟你碰到一样的问题，现在解决方式是，我们弄了一个监控程序，去刷这个WCF服务进程，如果这个进程不存在自动启动这个WCF服务，网络上还有另一种方式是用程序域来做，把整个WCF 运行在一个域里，如果域异常也是自动重启这个域。
------解决思路----------------------
http://www.cnblogs.com/snnhoo/p/4159982.html#3096182
https://devlib.codeplex.com/SourceControl/latest#main/product/Codes/DevLib.AddIn/AddInDomain.cs
https://devlib.codeplex.com/SourceControl/latest#main/product/Codes/DevLib.ServiceModel/WcfServiceHost.cs
可以用 AddInDomain 加载 WcfServiceHost ， 这样wcf服务会被加载到自动创建的独立的进程中（注意不是线程），当wcf crash的时候这个独立的进程会自动重启，而且wcf的crash也不影响到主进程。
我公司的项目我就是这么解决的，有时候不是wcf自身的问题，有时候是客户端或者是wcf提供的服务里用了别的库造成的问题，没办法全部try catch住，只能把wcf加载到独立的进程中，不会影响主进程，而且crash后可以自动重启，监控都用不着了
------解决思路----------------------
首先，你需要能够手工重复出来出错的操作方法。确保有70%以上的概率你能够让服务端垮掉。这是先决条件。如果你说“老是自动退出。不知道什么原因”，那你手工重现过问题吗？
其次，在没有 try...catch 的 Debug环境下运行服务端程序，让服务器端的bug尽早地被vs调试器捕获异常。不要采用任何隐瞒bug的try...catch，因为这只会让调试器无法捕获出错代码行，没有什么好处。
如果通过1似的你可以把问题缩小到一个小范围，但是你反复进行手工测试操作还是不能让vs调试器捕获到异常，那么就写一些日志。对于你手工重现bug所能够测试到的那一小部分代码，可以插入step1、step2、step3.....这样的日志。直到找到具体的某一条语句有异常。
写try...catch也好，还是另外弄个守护进程不断启动进程也好，这都是 Release 版本要做的事情。不是 Debug 版本要做的事情。谁也不会不让你正式发布的版本中容错，但是这不能解决 Debug。
------解决思路----------------------
注意不要过度猜测，不要在一些代码行上胡乱设置断点、日志。应该反复考虑测试，最后明确发现某几行代码抛出异常了，才开始调试。
从你的描述中，发现你总是定性地去假设什么理论造成程序崩溃。这时候就要想想“我是谁啊？我怎么就能靠理论就知道哪行出错啊？”，你要通过7、8次逐步缩小范围的方法来找到准确的异常代码行，千万不要让try..catch之类的转移bug的代码把你带到沟里去。
------解决思路----------------------
你在处理罗辑部份加这个try只能防的注业务部份的代码的异常，但防不住Wcf内部封装的异常，这这个我们也是这样处理的。
这种异常也是少见，但就是无去捕获。