The Year 2022 problem or Y2K22 bug is a programming error that occurred during the transition from 2021 to 2022. It affects programs that process time to the nearest minute, are limited to a two-digit year, and store this time in a signed 32-bit integer. It is related to the Year 2000 and Year 2038 problems. Example: December 31, 2021, at 11:59 p.m. is stored as the number 2112312359. January 1, 2022, at 00:00 is stored as the number 2201010000. The latter is greater than 2147483647, the largest value that can be stored in a 32-bit signed integer.
Microsoft Exchange 2016/2019 – as a first workaround, the antimalware scanner could be disabled, and on January 2, 2022, a first fix for the problem was released, which, among other things, removes versions of the malware patterns with ‘22’ at the beginning and continues the ascending numbering with ‘2112330001’ instead.
In the incidents described at the turn of the year, it is not yet known whether the bug described above is the cause or whether another error at the turn of the year caused the problem.
In Carinthia, Austria, the 2022 problem was the cause of a fault in the power grid on New Year’s Day, which resulted in a brief power outage for around 1,600 households. While Y2K22 didn’t have the global media storm of Y2K, but it proved that the risks of technical debt and overlooked edge cases are still very much present in modern infrastructures.
Since January 1, 2022, the clocks in some vehicle models manufactured by Honda and its subsidiary Acura, which obtain the time via the built-in GPS, jump back to January 1, 2002, every time the vehicle is restarted and cannot be corrected manually. Honda published repair instructions for service technicians on August 17, 2022, as the problem did not resolve itself as announced and the cause was not solely due to the internal counting method of the GPS clock.
The Y2K22 bug also blocked email delivery
At the beginning of 2022, many Exchange servers went down worldwide because the FIP-FS scan engine was crashing on the year. However, there was a temporary solution. As previously stated, the beginning of 2022 heralded an unexpected turning point. Exchange servers stopped working worldwide during email delivery.
The general impression was that the servers affected were those using the product’s built-in malware scanning feature.
A message stating “The FIP-FS Microsoft Scan Engine failed to load.” appeared in event logs. As a result, one of Microsoft’s first recommendations was to disable the service. The company provided a PowerShell script to perform this operation. Administrators reported that it was necessary to restart the transport service or even the entire server.
Year 2022 Bug : Converting the date value failed
The anti-malware scan engine encountered an error when converting the value “2201010001” to a long integer value, which prevented the process in question from loading. Julian Sieber had suspected, in a Tech Community comment dated December 31, 2021, that an overflow occurred when converting the string to a signed integer value. At the time, under PID 10816, the error codes 0x80004005 and the error description Cannot convert “2201010002” to Long were written to the log files.
Numerous affected users had reported the issue on the blog of the author of the original post, revealing that the problem occurred on various Exchange Server versions and different patch levels. However, not all on-premises Exchange Servers had been affected — it was suspected that the anti-malware scan or mail filtering had not been active on the unaffected systems.
Solution for the error: disable anti-malware scanning
For Exchange Server, there was a PowerShell script called Disable-AntiMalwareScanning.ps1 that disabled the scan engine. Running this script served as a temporary workaround. Afterwards, some users had to restart the transport service or even the Exchange Server.
Alternatively, the following PowerShell command could be used to temporarily disable mail filtering:Set-MalwareFilteringServer exch-19 -BypassFiltering $true
Here, too, the transport service likely needed to be restarted afterwards.
Another reader had informed the author of the article in a private Facebook message that, after executing the commandGet-TransportAgent “Malware Agent” | Disable-TransportAgent, email reception and sending under Exchange Server 2016 with the latest cumulative update was working again.
Microsoft had compiled some information on the topic in the article titled “Disable or bypass anti-malware scanning.” The author’s blog eventually included a user comment stating that Microsoft had already released a signature update to fix the problem. However, other administrators reported that this did not resolve the issue. Microsoft had not yet issued an official statement at the time.