Time problems often lead to several changes being made at once: registry edits, service restarts, manual clock adjustments and new peer lists. That usually makes the fault harder to understand.

Begin by checking the current source, status and effective configuration. Those three checks establish what Windows is doing before anything is changed.

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

What problem are you trying to solve?

The clock is wrong

Use this section when the displayed time is incorrect, drifting or changing unexpectedly. It covers large offsets, local clock fallback, sleep and resume, virtualisation hosts and manual adjustment.

The time source is wrong

Use this section when Windows reports an unexpected source such as Local CMOS Clock, Free-running System Clock, VM IC Time Synchronization Provider or the wrong domain controller.

Synchronisation fails

Use this section when w32tm /resync fails, no time data is available, the source cannot be contacted or Windows never completes a successful synchronisation.

Kerberos and authentication errors

Use this section when time skew is causing domain sign-in failures, service authentication problems or errors involving Kerberos tickets.

Domain controller time problems

Use this section when the PDC Emulator is using the wrong source, domain controllers disagree or the Active Directory hierarchy is not operating as expected.

Virtual machine time problems

Use this section when the guest clock changes after startup, migration, resume or snapshot restoration, or when both the hypervisor and Windows Time Service appear to be correcting time.

Windows Time event logs

Use this section to locate the relevant logs, interpret common warnings and distinguish routine source changes from persistent synchronisation faults.

A sensible troubleshooting sequence

For most problems, the following order avoids unnecessary changes:

  1. Confirm whether the computer is domain joined.
  2. Identify the role of the computer: workstation, member server, domain controller, PDC Emulator or standalone system.
  3. Check the source with w32tm /query /source.
  4. Check the last successful synchronisation with w32tm /query /status.
  5. Review the effective configuration with w32tm /query /configuration.
  6. Test the intended peer with w32tm /stripchart where necessary.
  7. Review DNS, UDP port 123 and the Windows Time event logs.
  8. Make one change, then verify the result before making another.

Do not start with the registry

Old guidance often begins with registry values such as SpecialPollInterval, AnnounceFlags, MaxPosPhaseCorrection or MaxNegPhaseCorrection.

Those settings may be relevant to a specific problem, but they are rarely the best place to begin. Most faults are caused by the wrong source, an unreachable peer, an incorrect domain hierarchy or competing virtualisation time synchronisation.

Do not rely on a successful command

A successful w32tm /config command confirms that Windows accepted the request. A successful w32tm /resync command confirms that a resynchronisation was requested.

Neither command proves that the intended source was selected. Always check the source and status afterwards.

Check the layer below Windows

Where the system is virtual, confirm that the hypervisor hosts have accurate time. Where the source is a firewall, NAS or Chrony server, confirm that the device itself is synchronised.

Many Windows Time problems begin outside Windows. The operating system cannot maintain accurate time from a source that is itself wrong or unavailable.

Related sections