犹记得当年的喜悦。故事有些长，就长话短说了。
背景
2017年，由个人主导的《xx门诊电子病历系统》在北京xxx第一次正式上线，这个系统集成了n家院内系统，如LIS、HIS、PACS等。涉及的交互，复杂无比。当时通过各个厂商讨论后，采用了进程间通信、api/webservice数据交互的方式，改造程序，完美的将程序集成在一起，让用户在一个系统中能够快速的工作，替代以往多客户端来回切换的工作方式。
而想要快速推广这种方式，需要厚实的功底。很可惜，我们的团队，并没有这种大牛。在开发之初，我就想到了以后可能需要和不同的医院作对接。因此，早期在搭建时，就设计了接口加反射的方式来实现不同医院的集成开发，实质是只要继承接口，实现接口即可。
问题就在这儿，并不是所有第三方提供的集成方式都稳定无比，也不是说我们的程序也能够稳定无比。
有些灾难性错误压根就不能捕捉。
随着系统逐步的推广上线了20多家时，我们研发越来越感到厚重。所有的问题，会越来越明确，越来越有统一性。
这个当中就有今天所说的灾难性崩溃处理。
处理过程
1.全局异常捕捉日志细化，然并卵，如delphi程序、c++程序并不能捕捉到
2.尝试反射出崩溃转存的文件，然并卵，我们这队伍并没有通用懂得汇编语言的人员。
3.要求第三方提供稳定的版本，依然，不是所有的人都能控制的。
4.折中方案，成功。
成功处理方案
我们都知道，通常一个exe程序就是一个进程。而我们程序因集成了很多第三方程序，进程中含有与第三方交互的地方很多。因此，引起崩溃，不能控制。
对此，我想到的就是将一个进程拆成多个进程的方式。不稳定的集成统统拆到子exe程序中，主程序与子程序间交互，崩溃的永远是子进程，主进程依然稳定运行。此方案，经过多现场改造后，很大的解决了现场压力。
意外收获
今天，看到博客园推荐的一篇文章，其实思想与我的想法一致。但是，他的做法更显功底，更有魅力。感谢博客园，感谢大家的奉献！
大家可以看看：https://www.cnblogs.com/cwsheng/p/14616685.html