Windows Time "Allowing" the OS Kernel to sync to CMOS clock after 24H of no valid time sync

Question

Hello,
I have been observing the following scenario with the following environment:
Windows 2008 Server R2
Not part of a domain
CMOS always clock drifted and not sync'd from the OS NTP Aware time.
1. Assume Windows Time has a problem syncing with a time source and produces the following when asked "w32tm /query /status /verbose":
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.2028500s
Root Dispersion: 7.8420074s
ReferenceId: 0x413738CE (source IP:  65.55.56.206)
Last Successful Sync Time: 2/1/2014 2:33:18 PM
Source: time.windows.com,0x9
Poll Interval: 10 (1024s)
Phase Offset: -0.0260539s
ClockRate: 0.0155992s
State Machine: 2 (Sync)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 2 (The computer did not resync because only stale time data was
 available.)
Time since Last Good Sync Time: 85499.5378040s
2. When "Time since Last Good Sync Time" arrives at the value 86400 (24H) an event log message such as the following is registered:
The time service has not synchronized the system time for 86400 seconds because none of the time service providers provided a usable time stamp. The time service will not update the local system time until it is able to synchronize with a time source. If the
local system is configured to act as a time server for clients, it will stop advertising as a time source to clients. The time service will continue to retry and sync time with its time sources. Check system event log for other W32time events for more details.
Run 'w32tm /resync' to force an instant time synchronization.
3. If the debug log of windows time was enabled with all the events (0-300) using "w32tm /debug .." The following records can be found in the log at the time:
 - W32TmServiceMain: timeout
 - ClockDispln GoUnsyncd: SetUnsync: LI:3 S:0 RDl:2184500 RDs:78611726 TSF:0x0
ReleaseClock2CMOS
 - Logging warning: The time service has not synchronized the system time for 86400 seconds because none of the time service providers provided a usable time stamp. The time service will not update the local system time until it is able to synchronize
with a time source. If the local system is configured to act as a time server for clients, it will stop advertising as a time source to clients. The time service will continue to retry and sync time with its time sources. Check system event log for other W32time
events for more details. Run 'w32tm /resync' to force an instant time synchronization.
 - W32TmServiceMain: waiting 642.223s
4. When the above occurs, we have observed that the OS Kernel would begin syncing to the underlying CMOS clock when they are different from each other in more than 60 seconds. The sync would occur on the next "sync point" which will arrive. A "Sync
point" is the end of a 60 minute cycle, counting from boot time and repeating.
Note: The CMOS clock could be off in more then 60 seconds for example when it's battery is dead, or on a virtualized environment under some conditions. (If anyone is interested in more details, please ask in the comment)
My Questions:
a. Parts of this behavior are well documented - can anyone confirm my analysis of the situation is correct?
b. Does anyone have knowledge of the term "ReleaseClock2CMOS" which appears in the Windows Time log? What exactly does it mean?
c. Under which conditions will the kernel avoid syncing to an underlying 60 seconds-off CMOS clock? Under which conditions will it sync (aside from what i described)?
Any info would be appreciated.

Answer 1

Hi,
Thank you for your question.
I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.
Jeremy Wu
TechNet Community Support