关于切换输入法时程序死机的问题

    前几天工程验证时发现一个问题，就是在文本框中切换输入法时程序会死机，而另一个版本的程序则不会。现有两个版本的程序在同时验证，且称它们为产品A和产品B。虽然不是同一个产品，但它们是基本于同一个平台，且大部分模块相同。那为什么产品A会出现这个问题而产品B不会出现呢？产品A在去年六月份曾发布过一个版本时也出现过这个问题，但后来从当前的.NET2003升级到.NET2005时就好了。但现在为什么还会出现呢，从不同的产品出现的情况不同着手分析如下。
    它们不同之处：一是有几个应用模块不同; 二是编译的机器不同（产品B是在同事的机器上编译的）；三是产品A中的一些界面是去年.NET2003开发的。
    针对上述分析，初步的解决方案为：
    1.将产品A在其他电脑上编译运行，看是否会出现相同情况。
    2.将产品A中的控件特别是TextBox用2005重新实现。
    3.安装微软最新版本框架Framework3.0。
    但结果都推翻了当前的判断，这些方案都没有效果。那么，网上又能找到什么答案呢？搜索结果归纳如下：
    1.更改textbox的ImeMode属性。
    2.输入法问题，有的五笔输入法有问题。
    3.程序中相关应用调用到的API函数与输入有冲突。
    4.使用了不适应VS。NET的控件。
    ......
    虽然贴子里面说法有多种，但一一试过后效果甚微，而且几乎找不到什么规律，在不同的条件下会出现的情况不同，比如启动监护时会出现，停止监护又不会出现等，但在其他条件下又推翻了这种规律判断。那问题到底出现在哪儿呢，此时我忽略了一个重要的问题，就是上述中关于应用模块的不同。接下来，我将产品A不同于产品B的模块一一去掉不加载，发现在将其中最重要的一个模块去掉后，这个问题就解决了。但这种规律会不会在将来的调试中又被颠覆呢，我几乎没有任何把握。这个被去掉的模块导致问题的可能性最大，一是因为它应用功能最多，且编译的DLL达到300多K；二是其中产程图一个文件的代码行数达到7000多行。是不是这些超出一定的限制而导致的问题呢，因为之前曾经有过因为DLL过大而导致了一些问题。
    针对这些问题我作了如下工作：
    1.将产程图文件分解，将其Control和Document分离到另外一个CS文件，将其中的关于控件的声明和初始化按照.NET2005的模式移到重新创建的*.designer.cs中（.NET2003是在同一个文件中）。
    2.将该项目分解。 结果让我快要崩溃了，仍然不行。那还是继续细化，找到细节的不同吧。首先我将目标放在产程图这个文件上（既然是这个项目出了问题，那玄奥一定在其中某个文件或某个类中），将关于产程的所有应用屏蔽掉，为了达到根除的目的，还将这些文件从项目中移除。
    运行起来后，果然不出所料，切换输入法时OK。 那问题进一步明朗了，但具体是什么原因呢？痛苦....
    由于产品等着验证通过，即将在下个月面市。而现在这个A类的产品问题却让这一切扑朔迷离，而作为当事人，我是首当其冲去承受这个压力了。除了加班别无选择，这几天都是加班到八点多。不过让人欣慰的是情形一步步在改观，这几天的辛苦没有白费。 经过几天的艰辛鏖战，真相渐渐浮出水面（调试的细节难以一一赘述）：
    1. 消息NotifyMonitorStopped发送出去后，有多个地方响应，而不同响应的地方执行代码时，都会加锁机制。如有的地方锁病人patient对象，有的地方锁床位文档cdocBunk对象，而这两个对象又有引用关联。所以不同的线程在执行这些操作时，都会等待对方解锁而造成死锁。
    2. 也是此消息的响应处，执行的操作与输入法的切换有冲突。
    针对该问题将该消息改为Post方式发送问题就迎刃而解了. 至于其中的具体原因，还不是太确定，需要更进一步地研究。 也许针对这个问题的本身，上面的一大堆费话还没有说清楚。只是作为这几天工作的一个记录吧。
    但我要想说的是： 解决问题的过程是痛苦的，但结果是让人会有成就感。技术的成长不就是这点滴的积累吗。如果逃避痛苦，除了不能享受结果的快乐，还会留下很多遗憾。只要你坚持，有足够的耐心和毅力，问题总会解决的。因为bug隐藏再深，但它是客观存在的，总有规律可循、有踪迹可查。