This article applies to Domain Time II.

Last Updated: 1 April 2015

Problem and Symptoms

Domain Time Server or Client logs report "Sync trigger detected - Clock Change: WM_TIMECHANGE broadcast detected" warnings. There may also be unexpectedly large time corrections, the system clock may run at the wrong rate, be unable to maintain stable time, or you may notice other time anomolies.

Cause

WM_TIMECHANGE broadcasts are internal Windows API messages generated by the system itself when any process changes the system clock. They are used to notify all other running processes that the system time has changed. Domain Time includes a special feature called Clock Change Monitor that (among other things) watches for these notifications and immediately triggers a resynchronization of the machine to its designated time source(s). If you see this log entry, it indicates that Domain Time has detected an unexpected clock change and has attempted to correct for it.

This message is almost always^* an error and an indication that some other user or program has unexpectedly changed the system time. Only one time service should be controlling the system clock (Domain Time in this case), and any other attempts to control the clock represent a serious issue. Either a user has manually attempted a clock change using the Windows Date and Time utility or some other program or utility has made the change. Such competing clock adjustments can result in incorrect clock rates, large time jumps, and may even prevent Domain Time from being able to correct the clock entirely.

^*You can see this message in normal operation if your system is adjusted for Daylight Savings Time by the operating system (either at the start or end of DST).

Solution

You will need to identify the user or process responsible for the errant clock changes and prevent the changes from occurring.

The most likely cause is that the Windows Time service (w32Time) has been re-enabled and is attempting corrections. In general, Domain Time disables the Windows Time Service, or, in some specific cases it can be set to "NoSync" mode (see the documentation for details). Be sure that on the Advanced page of the Domain Time applet the Windows Time mode dropdown is set to "Disabled", then restart the Domain Time Server service. Domain Time will then ensure W32Time is disabled. However, be aware that some W32tm commands can inadvertently restart it, so be careful of using that utility.

Another possible cause of unexpected clock change are time sync features of virtual machines. Be sure that the VMWare Tools/Hyper-V Integration Services Time Sync features are turned off for your VMs. Customers have reported instances where maintenance operations (such as snapshots or backups) on virtual hosts have also caused unexpected clock corrections. See KB2007.418 for more info on disabling other hypervisor time services.

Note that any other running process can be responsible for WM_TIMECHANGE broadcasts. Unfortunately, the broadcast messages do not include any information about the process that generated them. Other likely candidates are backup programs, media programs, custom trading applications, or even utilities that synchronize USB devices. You will need to use your detective skills to track them down. Windows event logs can often provide clues to the culprit from events that correspond to the times shown in the Domain Time logs.

Domain Time (as of version 5.2.b.20120206) includes a special logging mode that may help. On the Logs and Status page of the Domain Time applet, you can check the "Enable Time Change Event Monitor" checkbox. The Domain Time text log may then include more information on the source of the time changes. Note that this mode is fairly resource intensive, so you will not want to run this mode during normal operations - use it only for troubleshooting.

Once you have identified the cause of the time changes, you will want to reboot your machine to be sure that any issues with conflicting system timings will be cleared.