昨天凌晨，突然接到云南移动哥们的电话，说他们正在进行的全网割接出现了问题，当时只有我们的产品遇到这样的问题，其他省的其他厂商的产品都已经顺利通过测试了。迷迷糊糊的我无奈的起床，开机，查找问题，这也让我体会到了这几天北方的夜晚的冷啊。

花了一段时间对底层的协议包进行了分析，发现我们产品发出去的消息包的那个域后面的确随机的分布着一些乱码字符。譬如我们的消息发送的目的地址是1069999333(Google的短信搜索)，经过分析发现我们产品发出去的包中的这个域是这样的：3130 3639 3939 3933 3333 00f9 42 9678 0000 ….，一共是21个字节。粗略判断是我们协议栈发送功能实现的问题，但是又转念一想，虽说这个数据由瑕疵，但是数据接收方也是应该可以正确处理的啊，他们居然一反常态的校验出来其中的垃圾数据。之所以认为对方可是正常处理是因为对于这样的域，我们一般在业务层都会按字符串进行处理，大家都知道C语言中字符串是以''结尾的字符数组，那么对于上面例子中的那串数据，如果使用C中相应的字符串处理函数的话，是可以得到正确的信息:1069999333的，后面的垃圾数据会被最后一个3后面的''所隔开。

显然对方做了更加严格的校验了。也许当初实现我们的协议接口的同事太'单纯'了，没有想到对方'下手'会这么狠。开个玩笑罢了，其实归根结底还是我们自己实现的不完美导致的。早上上班来到部门，将事情和大家mail沟通了一下，居然另外一个项目组(其产品和我们属一类)发来邮件说这个问题他们早已经发现并修正了，但是忘记通知我们了。真是晕倒啊:)，这也说明了及时的沟通与交流多么必要啊！

上周日下午，接到同事的一个寻求支持的电话，原来是部门以前给中国联通做的一个运行在PC服务器上的程序在每天凌晨出现'挂死'情况，导致程序运行中断，问题连续几天复现。程序是老程序，在不下十多个省运行，一直都很稳定。通过联通的人发过来的截图，很难定位问题所在，所以只能打车到了联通机房现场查看了。

还是那句话，维护别人的又是自己不熟悉的程序那真是痛苦的，好久都不在Windows上写程序、调程序了，API都需要现到网上查。由于程序一直在现网运行，即使到了现场也依然只能从外围来看，把配置信息和一些现网数据拿到自己的Windows环境下进行模拟测试，看是否能够重现问题，可无论如何模拟都不能重现问题。

问题出在源代码中一处调用DeleteFile的地方，在凌晨那个时刻，DeleteFile总返回失败。微软的帮助文档给出了DeleteFile失败的一些原因，比如文件是只读的、文件是受保护的系统文件或者用户没有删除这个文件的权限等等。我们重点检查了那个出问题的文件夹中是否有特殊文件，将Windows设置成显示所有文件，包括隐藏文件后，依然没有发现。由于是现网主机，不便过多操作。

程序有个缺点就是没有后台日志输出，也许当初开发这个程序的同事也许开发惯了GUI的程序，没有意识到这应该是一个服务器端程序，居然在出错的时候弹出对话框，试想这个24 x 7小时运行的程序谁会眼睛一直盯着它和它交互呢，呵呵。这也是在出错的时候导致挂起的直接原因。

但是导致DeleteFile失败的深层原因还需要继续查找。经过和联通工作人员商量，决定做一次升级，增加后台日志，以便查到'幕后真凶'。

像联通这种效率不高的公司，做一个小小的升级走的流程都要耽误几天。这不昨晚才把升级程序替上去。上午我们技术支持人员将后台日志发给了我，打开一看居然是一个叫'autorun.inf'的文件导致的删除失败，通过FormatMessage和GetLastError配合得到的原因是"拒绝访问"，显然是这个文件的权限很高，即使用管理员权限也无法删除，甚至我们在屏幕上根本看不到这个文件的存在，只是通过Win32 API才能找到这个文件。这时我们的技术支持发来信息说：在网上查了一下，autorun.inf可能是病毒或者是木马；一句话点醒梦中人啊，我也在网上搜索了一下，的确这个autorun.inf是病毒的产物。这时我的同事又发过来一条信息说：联通人员确认过了他们的这台PC服务器居然一直在'裸奔'，就是没有安装任何防毒软件。我晕！

对这些运营商我就不再做太多评价了，地球人都知道。

通过这次事件我们也可以看到：实际软件运行时产生的问题真是多种多样，防不胜防啊。其实不考虑其他原因，我们的软件本身如果做的更好些的话，也是可以避免上述问题的发生的，细节我就不说了。