Microsoft’s #1 Bug of 2022 Allows Huge Numbers of Programmers to Work Overtime 24/7 – Research Snipers


Unexpectedly, the arrival of 2022 will also bring a new bug to Microsoft. As the date jumps from December 31, 2021 to January 1, 2022, many businesses using Microsoft Exchange have found that their written New Year’s greetings and other emails suddenly couldn’t be sent.

Exchange Server is a set of messaging service components launched by Microsoft, which can be used to create messaging systems for businesses, universities or institutions. Simply put, it can not only create a “mailbox workgroup”, but also coordinate internal workflows. A large number of mails are stuck in the mailbox servers of these companies, some even reaching hundreds of thousands, and they face the problem of server storage. At present, this bug has become popular on Reddit for thousands of people, and many people said that “fix the bug here after the year is up”: happy new year (beep)! I was still on vacation, so I brought him back to take care of this thing… So what’s going on? Microsoft 2022 “Millennium Bug” According to Joseph Roosen, an Exchange administrator, this is a bug caused by the arrival of “2022”. The root cause of this bug is the Message Filtering Management System (FIP-FS) on Microsoft Exchange, which uses a signed variable (Int32, which is long) called “yymmddHHMM” to store the date. Among them, yymmddHHMM refers to the use of two digits to store years (years), months (months), days (days), hours (Hours), minutes (Minutes).

There is a problem with this data type: Signed Int32 can only store data from -2147483647 to +2147483647 at most. However, as of 00:00 on January 1, 2022, the yy of “yymmddHHMM” changed to “22”, which exceeds the maximum range of data Int32 can store: 214748364722XXXXXXX As a result, on January 1, 2022, all companies who used Exchange servers to send email received such an error alert: The FIP-FS scan process failed during initialization. Error: 0x8004005. Error Details: Unspecified Error” or “Error Code: 0x80004005. Error Description: Unable to convert “2201010001” too long. Convert “2201010001” to long data type) It was first discovered by a Twitter user named @miketheitguy: since the same as the “Millennium Bug” is a bug brought to the computer by the date, this time , the bug was also named Y2K22 by some Exchange administrators. Among them, Y2K refers to the famous “millennium bug” problem. Since some computer programs only use two decimal digits to represent the year, erroneous results will occur when the century crosses over the century; 22 refers to 2022. This bug presents the same issue in many versions of Exchange Server including 2016 and 2019.

Currently, Microsoft’s Exchange team is fixing it urgently. They stated that an Exchange Server update will be released in a few days which will use a larger variable type to store the date. However, before that, companies that use Exchange Server need to find a way to send email. The Microsoft team of some expedients said that if a very urgent email needs to be sent, the FIP-FS feature in Exchange should be disabled first. This is a spam filter on Exchange. It is typically used to scan emails for malware or spam. Currently, Microsoft officials also offer methods to disable or bypass malware scanning. However, the consequence of this operation is that the company mailbox “may receive more spam”.

Some netizens ridiculed that, if Microsoft changes signed variables to unsigned variables in the repair, the data representation range will become 0~4294967295, and Exchange mailboxes can be used until 2043. Also, netizens from Reddit are currently offering other solutions. For example, a user posted an unofficial custom script that may go back to 2021, but said that all risk should be borne by the user. If you haven’t figured out how to fix your Exchange mailbox system problem, you can try these methods first.

Brian is the news writer at Research Snipers which primarily covers tech news, Microsoft News, Google News, Facebook, Apple, Huawei, Xiaomi and other tech news.


Comments are closed.