Windows 2019/2022 syncs to "hardware clock" and sets incorrect time

Anonymous
2024-07-16T17:41:14+00:00

I have encountered an issue on Windows Server (2019/2022) whereby the windows kernel spontaneously sets Windows time to the “hardware clock”. Even though the hardware (BIOS) clock seems correct, this changes Windows time to about 1 minute behind the real time. Windows Time (w32time) is disabled during this incident as I am using a 3rd party time sync software to keep windows time correct, so I do not think it is w32time that is causing the issue.

Event Viewer shows the following entry:

Source = Kernel-General

Event Id = 1

Task Category = (5)

The system time has changed to ‎2024‎-‎07‎-‎12T16:32:40.500000000Z from ‎2024‎-‎07‎-‎12T16:34:04.244113000Z.

Change Reason: System time synchronized with the hardware clock.

Process: '' (PID 4).

I have encountered this issue on both Windows 2019 and 2022 multiple times.  Thankfully it seems rare (maybe once every month or two) but has happened multiple times on the same server.  Older versions like Windows 2012 R2 have never experienced this problem.  We are running Dell R440 and R450 servers. 

Why would Windows suddenly try to sync the clock to “hardware time”?  And why is it always about 1 minute behind the actual time? Even if BIOS/hardware time was incorrect, why would Windows try to sync to it?

Windows for business | Windows Server | Directory services | Other

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.

0 comments No comments
{count} votes

8 answers

Sort by: Most helpful
  1. Anonymous
    2024-07-17T03:18:26+00:00

    Hi BrianJ BB,

    Thank you for posting in the Microsoft Community Forums.

    w32time is a service for time synchronization in Windows, which can get the time from an external NTP server and synchronize the system time. If this service is disabled, the system may not automatically correct for time skew.

    In some cases, the system may be configured to fall back to using a hardware clock under certain conditions, such as network unavailability or time synchronization service failure. This can be achieved through registry settings or Group Policy.

    If the system experiences a failure of the time synchronization service, such as a third-party software failure or network issue, it may attempt to fall back to using a hardware clock as the time source.

    For BIOS Clock Skew:

    The most immediate reason is that the BIOS clock itself is biased. This deviation can be caused by a low CMOS battery, incorrect BIOS settings, or hardware failure.

    Even if the BIOS time is correct, the system may have made the wrong adjustment of the time due to some reason during the boot process (such as incorrect time zone setting, improper daylight saving time adjustment, etc.).

    Suggestions for resolution

    Make sure the BIOS time is set correctly and that the CMOS battery is sufficient.

    Consider re-enabling the w32time service and configuring it to synchronize time from a reliable NTP server. This helps to ensure the accuracy of the system time.

    Make sure that the third-party time synchronization software is installed correctly and configured to run automatically. If there is a problem with the software, consider updating or replacing it with another reliable software.

    Check the system log for more information about time synchronization errors. This helps to identify the root cause of the problem.

    Best regards

    Neuvi Jiang

    0 comments No comments
  2. Anonymous
    2024-07-17T18:49:21+00:00

    The system clock is kept in sync by the third party software. I use third party time sync software because it is more precise (millisecond level) than the w32time service and it keeps a log of updates and skew. So the issue is not a problem with Windows time becoming inaccurate - if anything it is more accurate than w32time would provide.

    The problem is not the 3rd party software as the Event Viewer clearly shows the Windows kernel updating the time, even though the system time was accurate at that point.

    As far as I can tell the BIOS clock is also in perfect sync. This problem does not occur on boot, but typically after 1+ months of server uptime. I first had this happen on a Windows 2019 server not internet connected (but kept in time sync from a local NTP server) and thought that was perhaps the cause. But then it recently happened on a new Windows 2022 server that is connected to the internet.

    In short it seems that system time is fine, BIOS time is fine, and these are both late model servers (one is only a few months old) so very unlikely CMOS battery or hardware issues.

    Is there a way (registry setting or group policy) of telling Windows to never attempt to sync with the hardware clock? Again, this is a Windows kernel level update (not w32time) as the event log shows it as such. The potential solutions I've found on the internet seem to be fixing problems with w32time but in my case since w32time is not running I am not sure of what settings might solve this problem. Thanks.

    0 comments No comments
  3. Anonymous
    2024-07-18T00:56:05+00:00

    Hi BrianJ BB,

    Have a nice day!

    In Windows, it is not a standard practice to explicitly indicate "never attempt to synchronize with a hardware clock" directly through registry settings or Group Policy, as Windows systems are designed by default to manage and maintain consistency between system time and hardware clocks (i.e., CMOS or RTC, real-time clocks). This is an operating system-level setting and cannot be changed in most cases.

    Best regards

    Neuvi Jiang

    0 comments No comments
  4. Anonymous
    2024-07-19T17:50:04+00:00

    Hello BrianJ,

    Try calling the Win32 function GetSystemTimeAdjustment and check the third output parameter (lpTimeAdjustmentDisabled). You may well find that this has the value "TRUE".

    The documentation says:

    A value of TRUE indicates that periodic time adjustment is disabled, and the system time-of-day clock advances at the normal rate. In this mode, the system may adjust the time of day using its own internal time synchronization mechanisms.

    The difference between the running system time and the CMOS Real Time Clock time is periodically checked. If the difference exceeds 60 seconds, the running system time is "corrected" .

    Gary

    1 person found this answer helpful.
    0 comments No comments
  5. Anonymous
    2024-07-21T15:21:40+00:00

    Gary,

    Thank you for the reply. The "60 seconds difference" makes sense as the time adjustments have only been slightly greater than 1 minute. Also I noticed that the problem only occurs after maybe 1 or 2 months of system uptime. So far I have not seen it occur on a server that was recently booted (within the past week or so). Perhaps there is some Windows internal tracking of the BIOS clock that skews over time (eg. since the last boot) and after a month or two creates this discrepancy. When I recently checked the BIOS time on both affected servers (booting into BIOS and checking the clock) the times were perfectly in sync with the correct time, so it does not appear there is an actual discrepancy in BIOS time.

    In the meantime I've scheduled the affected servers to reboot automatically every weekend, hoping this will prevent the issue if it is indeed related to longer uptimes. I'll do some more research based on your comments and examine those settings, as well as see if I can find a way to track BIOS vs Windows time (via Win32) to see if I can detect a perceived discrepancy before the problem occurs.

    Regards,

    Brian

    0 comments No comments