Windows Time Event Logs

Windows Time events are useful, but they should not be read in isolation. A warning generated while the network is starting may be followed seconds later by a successful source selection. The same warning repeated for several hours points to a real problem.

Before acting on an event, record:

The computer role: workstation, member server, domain controller or forest root PDC Emulator.
The event time and the events immediately before and after it.
The source reported by Windows Time Service.
Whether the computer had just started, resumed, migrated or changed network.

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

Where to find Windows Time events

The most familiar events are written to:

Event Viewer
  Windows Logs
    System

Filter the System log by the source:

Microsoft-Windows-Time-Service

Older Windows versions and older articles may refer to the source as W32Time.

Modern Windows versions also provide a more detailed operational channel:

Event Viewer
  Applications and Services Logs
    Microsoft
      Windows
        Time-Service
          Operational

The Operational log is particularly useful when trying to establish when the source changed, when a resynchronisation was requested or when the service altered the system clock.

Common System log events

The exact wording can vary between Windows versions. The table below describes the events commonly encountered when troubleshooting supported Windows and Windows Server releases.

Event ID	Typical description	What it usually means	What to check
12	The time provider is configured to acquire time from the domain hierarchy, but this computer is the PDC Emulator at the root of the forest.	The forest root PDC Emulator has nowhere higher in Active Directory from which to obtain time.	Configure the forest root PDC Emulator with approved external peers or a deliberate internal reference. Do not apply the same manual configuration to every domain controller.
24	NtpClient has no source of accurate time.	Windows has lost its usable source and is searching for another one. It can occur briefly during startup, network changes or virtualisation corrections.	Look for a later success event. If it repeats, check the selected source, domain hierarchy, DNS and UDP port 123.
29	NtpClient is configured to acquire time from one or more sources, but none of the sources are currently accessible.	The configured peers did not provide usable NTP responses.	Check peer names, DNS, firewall rules, UDP 123 and whether the upstream server is synchronised. On a virtual DC, also check for competing host time synchronisation.
35	The time service is now synchronising the system time with a named source.	Windows has selected a source and started using it.	Usually no action. Confirm that the named source is the one expected for the computer's role.
37	NtpClient is receiving valid time data from a named source.	The source is responding with usable time data.	Usually no action. A valid response does not by itself prove that the source is the preferred organisational source.
38	The time provider reports a change involving the selected source or clock correction.	Often appears with Events 24 and 29 on older virtualised domain controllers when host and domain time mechanisms compete.	Review nearby events and the hypervisor time settings. Do not interpret Event 38 without its event text and surrounding sequence.
47	NtpClient received no valid response from a manually configured peer after repeated attempts.	The peer is configured, but Windows is not receiving a usable response.	Test DNS and the peer with `w32tm /stripchart`; check UDP 123, client mode flags and the NTP server's own synchronisation state.
50	The time service detected a time difference greater than the permitted correction or encountered a large clock adjustment.	The local clock and source differ substantially, or the effective correction limits prevented the change.	Find the cause before increasing phase-correction limits. Check the hypervisor clock, snapshots, CMOS battery and the trustworthiness of the source.
129	NtpClient was unable to set a domain peer because of a discovery error.	A domain member or domain controller could not discover a suitable source through Active Directory.	Check domain connectivity, DNS, site configuration, DC advertising and whether the computer should use `NT5DS`.
134	NtpClient was unable to set a manual peer because of a DNS resolution error.	The configured hostname could not be resolved.	Correct the peer name or DNS record. Check resolution from the affected computer and look for an obsolete value supplied by Group Policy.
142	The time service has stopped advertising as a time source.	The computer no longer meets the conditions for advertising usable time. On a domain controller this can affect source discovery by clients.	Read the reason in the event: the machine may not be a DC, no providers may be running, or the local clock may be unsynchronised. Correct that underlying condition.

How to read the table

The event number is only the starting point. The complete event text matters because the same event can include different sources, status codes and reasons.

For example, Event 142 can state that the computer is not a domain controller, that no providers are running, or that the local clock is not synchronised. Those are different conditions and should not receive the same repair.

Events that normally indicate success

Events 35 and 37 usually indicate progress rather than failure:

Event 35 identifies the source with which the service is now synchronising.
Event 37 confirms that valid data is being received.

Still check the source name. A successful synchronisation with VM IC Time Synchronization Provider may be appropriate for a deliberately host-synchronised standalone VM, but unexpected on a domain controller intended to follow Active Directory.

Events that often occur together

A typical temporary sequence during startup might be:

Windows initially has no usable source.
Event 24 or 29 is logged.
DNS and network connectivity become available.
A suitable source is selected.
Event 35 or 37 confirms successful synchronisation.

That sequence is generally not a fault.

A persistent problem looks different:

Event 24, 29, 129 or 134 is logged.
The retry interval increases.
The same warning returns repeatedly.
No later event confirms a valid source.
w32tm /query /status shows an old or missing successful sync.

Event 12 on the forest root PDC Emulator

Event 12 is one of the clearest configuration warnings.

The forest root PDC Emulator is at the top of the Active Directory time hierarchy. Configuring it to use NT5DS or DOMHIER gives it nowhere valid to go.

Configure that server with the approved upstream source:

w32tm /config /manualpeerlist:"0.uk.pool.ntp.org,0x8 1.uk.pool.ntp.org,0x8 2.uk.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update

Use the organisation's chosen peers rather than copying the example without review.

Events 24, 29 and 38 on virtual domain controllers

Microsoft documented Events 24, 29 and 38 occurring together on older Hyper-V virtual domain controllers where the guest was receiving time both from Active Directory and from the host integration service.

The underlying lesson remains relevant even though current hypervisors and Windows versions have evolved: two separate mechanisms should not compete to maintain the domain controller clock.

For virtual domain controllers, preserve the Active Directory hierarchy and review the platform-specific handling of ongoing and one-off host corrections.

Events 129 and 134

These events help separate two common failures:

Event 129: Windows could not discover a suitable domain source.
Event 134: Windows could not resolve a manually configured peer name.

Event 129 points towards Active Directory, DNS, sites, DC advertising or domain connectivity. Event 134 points directly towards the configured hostname and DNS resolution.

Event 142 and advertising

Event 142 matters most on a domain controller or another computer expected to provide time to clients.

The event text identifies why advertising stopped. Common reasons include:

The local computer is not a domain controller.
No time providers are running.
The local clock is not synchronised.
The computer no longer qualifies as a good time source.

On a domain controller, confirm:

dcdiag /test:Advertising
w32tm /query /source
w32tm /query /status

The Operational log

Windows 10 version 1703 and later, and Windows Server 2016 version 1709 and later, include traceability events in the Time-Service Operational channel.

Microsoft documents Events 257 through 266 for this purpose. They record changes and state that are useful when reconstructing what happened to the clock.

Event range	Recorded information	Why it is useful
257-258	Windows Time Service start and stop information, including UTC time and system tick count.	Shows whether the service restarted around the time of the fault.
259	Periodic NTP client status, available sources and the selected reference source.	Provides a historical view of which peers were available and which one was chosen.
260-266	Configuration, source, stratum, resynchronisation and clock-adjustment changes.	Helps establish whether the source changed, a resync was requested or Windows altered the clock or clock rate.

For exact field definitions, use Microsoft's Windows Time traceability documentation. The detailed content can vary by operating-system build.

Query events with PowerShell

Recent Windows Time events from the System log can be displayed with:

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Time-Service'
} -MaxEvents 50 |
Select-Object TimeCreated, Id, LevelDisplayName, Message

To query the Operational channel:

Get-WinEvent -LogName 'Microsoft-Windows-Time-Service/Operational' -MaxEvents 100 |
Select-Object TimeCreated, Id, LevelDisplayName, Message

Export the results before clearing logs or making widespread configuration changes.

Filter around the time of the fault

Rather than reading every event, start with the time at which the authentication failure, clock jump or migration occurred.

Correlate Windows Time events with:

System startup or service restart.
Network link changes.
Group Policy refresh.
Hypervisor migration, resume or snapshot tasks.
Kerberos, Netlogon and KDC errors.
DNS client failures.

Several logs describing the same minute are usually more valuable than hundreds of Windows Time events viewed without context.

When to enable debug logging

Windows Time Service supports detailed debug logging, but Microsoft recommends using it only after the normal troubleshooting steps have been completed.

Debug logging can generate a large amount of low-level information. Before enabling it, check:

The selected source and effective configuration.
DNS and UDP port 123.
The upstream server's synchronisation state.
Domain hierarchy and DC advertising.
Virtualisation time settings.
The System and Operational event logs.

Where deeper evidence is required, follow the current Microsoft procedure rather than copying old registry values from an archived article.

A practical interpretation sequence

Read the complete event text, not only the ID.
Check the events immediately before and after it.
Identify the role of the computer.
Run the source, status and configuration queries.
Determine whether the event was transient or repeated.
Check DNS, UDP 123 and the upstream source if no valid data was received.
Check Active Directory advertising and hierarchy on domain systems.
Check the host and guest tools on virtual machines.
Confirm a later successful synchronisation after making one change.