微软exchangeserver中的bug 新年伊始

新年伊始，微软ExchangeServer2016与2019中出现日期检查错误，导致服务器无法正确识别2022年这一时间标记。因此也有人称其为Y2K22bug ，即千年虫2022版。
据悉，微软的邮件程序会将日期与时间存储为signed整数（带符号的整数），最大值为2147483647 ，即2^31-1 。而微软使用更新版本的前两位数字表示其发布年份，所以只要时间在2021年或更早，那就一切OK 。然而，就在微软于新年前夜发布2201010001版本时，本地服务器却由于无法正确解析日期而发生崩溃，导致递送消息卡在传输队列中动弹不得。
世界各地的管理员疯狂排查故障，错过了与亲朋好友一同迎接新年的宝贵时光。“微软到底在搞什么鬼？马上要过年了，要不是论坛上说大家普遍遇到了问题，我们就要重新跑回去上班了。”一位管理员在Reddit线程中写道。
微软在次日发布了修复方案：自动PowerShell脚本和脚本也无法运行时适用的手动解决方案。无论如何，管理员都需要在受到影响的每台本地Exchange2016与2019服务器上分别执行修复操作。好在自动化脚本可以在多台服务器上并行运行。微软公司强调，自动化脚本“可能需要一段时间才能运行完成” ，并呼吁管理员们耐心等待。
日期与时间检查是在Exchange检查FIP-FS版本的过程中执行的， FIP-FS是一种扫描引擎、属于Exchange反恶意软件保护机制中的组成部分。一旦FIP-FS的版本是以数字22开头，则检查将无法完成、投递中的邮件也会被突然叫停。微软发布的修复程序会停止Microsoft筛选管理与MicrosoftExchange传输服务、删除现有反病毒引擎文件，并安装和启动经过修复的新反病毒引擎。
目前，大部分受到波及的组织已经恢复正常，但还不清楚这项bug已经存在了多久，不过从受影响的版本判断，很可能源自ExchangeServer2016的开发阶段。
一直在重蹈覆辙
从根本上说，千年虫是一种程序处理日期上的bug ，这并不是严重的技术问题，但却是企业们一直在犯的错误。
2019年11月，部分惠普SSD固态硬盘在运行32768小时后自动停止工作，盘内存储内容全部消失且无法恢复。特定系统中的所有驱动器可能都预装有相同批次的固件、有着同样的bug隐患，一旦同时发生故障，即使是RAID系统也承受不了这种“集体罢工”式的极端状况。
惠普并没有做出具体解释，而是直接发布了固件修复升级。但从现象来看，问题应该是与代码中的16位值有关。这意味着此系统可负载的最大负整数是32768 ，最大正整数则是32767 。
数字溢出问题是最为常见的编程错误之一，一旦值达到极限条件而且未经溢出或下溢检查的校正，那任何代码都有可能出现问题。因此，很多开发者喜欢用超级大的整数进行标定；只要数字够大就不怕意外溢出。
不过，这招并非百试百灵。微控制器中只能使用8位或者16位整数。考虑到这些值往往与外围控制器相关联，所以必须要为其设置适当的范围限制，确保开发者和代码审查者能够准确掌握这些重要数值。
另一方面，这类超限状况常常引发难以发现的bug 。惠普SSD事件中，驱动器要运行几年才能达到极限时长，所以这种在罕见条件下才会触发的错误确实不易被察觉。如果这块SSD恰好服务于某台自动驾驶汽车，那么在它停止工作的瞬间，车辆很有可能引发严重的交通事故。
除了惠普SSD事件，阿丽亚娜-5运载火箭首次测试发射失败的原因也是这样的一个“小”失误。1996年6月4日，阿丽亚娜-5运载火箭首次测试发射，火箭在发射后37秒被迫自行引爆， 40秒后解体。这个价值5亿美元的运载系统瞬间灰飞烟灭。