https://bugs.winehq.org/show_bug.cgi?id=53171
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #2 from François Gouget fgouget@codeweavers.com --- I suspect this was caused by Windows' Secure Time Seeding: https://arstechnica.com/security/2023/08/windows-feature-that-resets-system-...
To summarize the article, w32time tries to defend against dead CMOS clock batteries and bad BIOSes messing the clock by using the time from the ServerUnixTime field of various SSL connections to compute a 'high probability' time interval and reset the computer's time if it is not in that interval. However w32time sometimes guesses wrong, thus setting the time back or forward by hours or days. This may be compounded by OpenSSL putting random data in that field since 2014 so w32time is getting less reliable data from it.
One can check Windows' guess as to the plausible time range in the following registry key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits] See SecureTimeEstimated, SecureTimeHigh, SecureTimeLow, RunTime\SecureTimeConfidence
It's not clear if w32time initiates SSL connections itself, to which hosts, or somehow gets information some other way. In any case building the range may take a bit of time which could explain why this happens during a test rather than immediately on startup.
In any case, if this is the issue, a workaround would be to set the following registry value:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config] UtilizeSslTimeData = 0
But then the TestBot has been disabling w32time entirely since December 2022 (the VMs were updated over a couple of weeks) which should also avoid this issue entirely. Indeed this issue does not seem to have happened in the past 8 months (so going back to 2022-12-16).
So I think this can be considered to be fixed.