微信挂死为哪般？

    大家都常用微信吧？肯定的啊。那么，遇到过微信程序出问题么？”有还是没有？”哈哈，这个问题不好回答了，“没有啊，挺稳定的”，“好像有过，界面一闪就消失了，但再启动就好了”，“前段时间，遇到一串奇怪字符就死”

    不轻信不迷信，本于事实说话，老雷昨天真的遇到微信程序出现问题，而且还是比较严重的问题。  

    首先澄清一下，出问题的是微信的PC版本，不是手机版本。为了便于区分，不妨把PC版本称为“微信大程序”（与手机上的小程序之名对应）。

大程序挂死

    大多时候使用微信小程序就够了，这一次启动微信大程序的原因是为了从手机向PC传递文件。传递文件后就没有关闭它。昨天下午，有朋友发起语音聊天，托盘区域弹出漂亮的提示界面。看到后，我知道是要开一个约定好的“电话”会议。犹豫了一下是该在PC上接听，还是从手机上接听。考虑到伏案半天了，想站起来活动活动，于是就拿起手机接听。20多分钟后，会议结束，放下手机，坐到电脑前，看到托盘区域的语音聊天提示还在。当时就有点好奇，不知道腾讯的同行是如何设计这个逻辑的，如果手机接听了，是不是应该把PC上的这个提示自动关闭啊？还是允许两边同时接听，诶呀，还挺复杂的......

    一边想，一边移动鼠标想把这个提示界面关闭掉。但是鼠标移过去后，光标的形状由尖尖的箭头变为一个圆环，中心透明。在窗口里移动鼠标，圆环跟着移动，移动的同时在不停的旋转。尝试着把鼠标移动到按钮，没有任何变化，仍是不停的旋转。看起来，窗口里的所有元素都都凝固成了一团，分不出按钮还是背景。点击鼠标，感觉硬邦邦的，点不动，似乎一切都冻结了，冻得还很牢，仿佛严冬的水面经历过了零下40度的低温......

    过了几秒钟再点击，出现了一个对话框。上面写着：“WeChat未响应”。

    

    根据老雷多年的经验，可以很肯定的说：微信挂死了。准确地说，是微信大程序挂死了。

上调试器

    今天的软件太复杂了，程序本身复杂，环境也复杂，二者对接，复杂度以排列组合的方式激增。CPU在五花八门的各类函数间纵横驰骋，所到之处难以预估。而其中任何一个地方出问题，都可能导致CPU脱离正常轨道，出现上面所描述的情形。

    那么，是到底是什么问题导致洋洋微信大程序翻身落马，动弹不得呢？

    或许有人说，费什么事啊？重启算了。

    非也，一旦重启就湮灭了第一手的证据，错过了找到问题根源的最好机会。接下里便可能有一大堆模棱两可的推测，或者稀里糊涂地产生一些错误结论，甚至冤假错案。作为一个认真的软件工程师，怎么能那么不负责任呢？不禁想起《窦娥冤》里的经典台词：只合把清浊分辨，可怎生糊突了盗跖，颜渊？

    闲言打住，上调试器。

    唤出WinDBG，尝试附加到WeChat进程，失败，错误码5，访问被拒绝。以管理员方式运行WinDBG再试，成功。看来微信大程序是以较高权限运行的（为何？姑且不论）。

    因为是界面挂死，直接观察0号UI线程的执行轨迹。    

    从下向上看，虽然因为缺少腾讯模块的调试符号，少了一些信息，但是总的执行脉络还是很清楚的，#1d是编译器的入口函数，#1c是WeChat程序的Main函数，而后进入WeChat程序的主DLL，调用导出函数StartWechat，而后是消息循环（#18-19），之后应该是某个消息触发执行消息处理函数，在处理消息的过程中，调用了waveInOpen API。查看这个API的文档，可知其精确的函数原型。

MMRESULT waveInOpen(

   LPHWAVEIN       phwi,

   UINT            uDeviceID,

   LPCWAVEFORMATEX pwfx,

   DWORD_PTR       dwCallback,

   DWORD_PTR       dwCallbackInstance,

   DWORD           fdwOpen

);

    waveXXX系列API是Windows平台上经典的多媒体编程接口，用来输出和输入声音，从函数名中的waveIn看便知道它是用来接收声音（录音）的。如此看来，微信程序的UI线程是在打开录音设备时遇到了障碍，并且卡住不能动了。

    浏览进程中的其它线程的执行轨迹，发现有多个线程在执