Windows Time Synchronization (w32time) and Business Systems — Solving "The Log Timestamps Don't Match" from the Mechanism Up

“The machine stopped unexpectedly. We lined up the device’s log against the application log on the PC, and the timestamps were 40 seconds apart — so we can’t say whether the device error or the application’s loss of communication came first.” That is a scene we have met over and over in failure investigations on device-integrated systems. Network cameras, PLCs, inspection equipment and Windows PCs: each of them stamps its logs with its own clock, and nobody, it turns out, had ever guaranteed that those clocks agreed.

Time drift goes almost entirely unnoticed in normal operation. It bites during a failure investigation — precisely when “which event came first” is needed as evidence. And once you start digging, the facts pile up: “the workgroup PCs were only synchronizing once a week”, “the virtual machine was being pulled by both the host and NTP”, “nobody had ever set the device’s clock at all”.

This article is for developers and IT staff who have struggled to reconcile logs between devices and PCs, or between servers and clients. It covers how the Windows Time service (w32time) works, the practical side of diagnosis with the w32tm commands, realistic expectations for accuracy, and how to design the business system itself on the assumption that “time drifts and time goes backwards” — all backed by Microsoft’s primary documentation.

1. The Bottom Line First

• Windows time is managed by the Windows Time service (w32time). It is not a strict implementation of NTP, but it is an NTP client/server that uses the NTP specification’s algorithms to discipline the clock, communicating over UDP port 123.¹
• A domain environment has a fixed time hierarchy. Members synchronize with a DC, DCs synchronize with a DC in the parent domain, and at the top sits the PDC emulator of the forest root domain. If the top is not synchronized with an accurate external time source, the whole domain is wrong in unison.¹
• Workgroup (non-domain) machines synchronize with time.windows.com at a low frequency by default. The registry default for SpecialPollInterval is 604,800 seconds (one week) in a standalone configuration. Drift of tens of seconds happens “exactly as designed”.²³
• The w32tm command set is all you need for diagnosis. w32tm /query /status for sync state and source, /stripchart for measuring the actual offset against a peer, /config /manualpeerlist to specify what to synchronize with, and /resync to force an immediate resynchronization.²
• w32time corrects small offsets gradually via clock rate (slewing) and large offsets by setting the clock directly (stepping). In other words, the system clock can jump both forwards and backwards. It is equally important that once the offset exceeds the limits (MaxPos/MaxNegPhaseCorrection), no correction is applied at all and the event is merely written to the event log.¹²
• The design goal for default-configuration accuracy was “enough to satisfy the Kerberos five-minute constraint”. Windows Server 2016 / Windows 10 1607 and later improved this substantially, and 1 second / 50 ms / 1 ms accuracy became supported provided conditions around an accurate Stratum 1 time source, network latency, hop count and so on are met.⁴
• A Hyper-V guest has two time providers: the host and NTP. From Windows Server 2016 onward the guest was improved to pick whichever is best, but for domain-joined guests on 2012 R2 or earlier, disabling the Hyper-V time synchronization provider is recommended.³
• On the application side, design for the assumption that time drifts and time goes backwards. Record log times in UTC, and measure elapsed time with Stopwatch, which increases monotonically and independently of the system clock. That division of labor is the foundation.⁵⁶

2. How w32time Works — Domain and Workgroup Behave Completely Differently

The Windows Time service (W32Time) is the standard time synchronization component in Windows. It obtains time samples from network time sources over NTP (and the secure MS-SNTP variant used within a domain), picks the best sample using NTP’s clock filter and clock selection algorithms, and adjusts the local clock.¹

The thing to understand is that the way the synchronization target is decided differs fundamentally by configuration.

In a domain environment (Type=NT5DS), the AD DS forest has a predetermined time hierarchy. Member PCs and servers synchronize with a DC in their own domain, DCs synchronize with a DC in the parent domain, and at the top of the hierarchy is the PDC emulator of the forest root domain (or a DC configured as a reliable time source). NTP packets are signed with a Kerberos session key, and only authenticated time is accepted.¹ As a result, PCs within a domain usually agree reasonably well with each other. The problem is at the top: if the PDC emulator is not synchronized with an accurate external time source (a GPS clock or a trustworthy NTP server), everyone is wrong together. That drift becomes visible the moment you reconcile your logs against a system outside the company or a record held in the cloud.

In a workgroup environment (Type=NTP), the default synchronization target is time.windows.com,0x1. The 0x1 flag (SpecialInterval) means the polling interval is taken from the SpecialPollInterval registry value, whose default is 604,800 seconds = one week in a standalone configuration.² Even a Windows 10 client only polls about once a day, and the default for the Windows Server 2012 R2 generation was once a week.³ A PC’s internal clock (a crystal oscillator) routinely drifts by seconds a day depending on temperature and other environmental factors, so a weekly sync makes drift of tens of seconds entirely normal. That is usually the whole story behind the “40 seconds out” from the opening.

The other thing that matters in practice is clock discipline behavior. While the offset is small, w32time speeds up or slows down the rate at which the clock advances and converges gradually (slewing); once the offset exceeds MaxAllowedPhaseOffset, it sets the clock directly (stepping).¹² Furthermore, if the offset exceeds MaxPosPhaseCorrection/MaxNegPhaseCorrection (standalone default 54,000 seconds = 15 hours), it logs an event without correcting anything at all.² When “it’s supposed to be synchronizing but it never gets fixed”, this limit is sometimes what you have hit. And step corrections apply in the negative direction too — that is, the Windows system clock can jump backwards — which is what leads into the application design discussion later on.

3. Working With the w32tm Commands — Check the State, Measure the Offset, Change the Source

There are effectively five commands you need for time-related investigation. All of them are run from an elevated command prompt.²

Start by checking the current state.

w32tm /query /status

Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0312500s
Root Dispersion: 7.7756348s
ReferenceId: 0xC0A80A14 (source IP:  192.168.10.20)
Last Successful Sync Time: 7/22/2026 8:14:02 AM
Source: dc01.example.local
Poll Interval: 10 (1024s)

Three things are worth looking at. Whether “Source” is the peer you intended (Local CMOS Clock or Free-running System Clock means effectively unsynchronized); whether “Last Successful Sync Time” is recent (days ago means synchronization is not working); and whether the “Stratum” is plausible (how many hops from an accurate time source — w32time only accepts Stratum 15 or below).⁷ If you only want the source, use w32tm /query /source; for the state of multiple peers, w32tm /query /peers; and for the configured values along with where they came from (policy or local), w32tm /query /configuration.

Next comes measuring the actual offset against a peer. This is what you use in a failure investigation to put a number on “how far apart are the server and this PC right now”.

w32tm /stripchart /computer:192.168.10.20 /samples:5 /dataonly

Tracking 192.168.10.20 [192.168.10.20:123].
The current time is 7/24/2026 9:41:03 AM.
09:41:03, +28.1246875s
09:41:05, +28.1250120s
09:41:07, +28.1248533s
09:41:09, +28.1251008s
09:41:11, +28.1249517s

From this example you can conclude immediately that “this PC is roughly 28 seconds behind the peer”. Because /stripchart is a measurement for display and does not change the local clock, you can run it safely even on a production device PC. Running it against every machine involved before you start reconciling logs and building an offset table first is the very first thing we do in a failure investigation.

To specify the synchronization source explicitly, use /config. The standard way to point a machine at an internal NTP server (or a DC) looks like this.

w32tm /config /manualpeerlist:"ntp1.example.local,0x8 ntp2.example.local,0x8" /syncfromflags:manual /update
w32tm /resync

0x8 is the flag for synchronizing in client mode; combining it with 0x1 (SpecialInterval) — that is, ,0x9 — polls at the interval given by SpecialPollInterval. Because 0x1 on its own drops the client-mode flag, you should specify either ,0x8 or ,0x9. If you can only provide two servers, adding 0x2 (UseAsFallbackOnly) to one of them to make the priority explicit is recommended (Microsoft’s guidance being that three or more servers would be better still).² To stop specifying peers manually and return to the domain hierarchy, run w32tm /config /syncfromflags:domhier /update and restart the service. w32tm /resync discards accumulated error statistics and forces an immediate resynchronization; use it to confirm that a configuration change has taken effect.²

Note that an external NTP source specified with /manualpeerlist is a different thing from authenticated domain time and is not authenticated, so as a rule it should not be used on domain members — it is for the top of the hierarchy (the PDC emulator) and for non-domain machines.¹

4. About Accuracy — How Close Does the Default Get You, and What 1 ms Requires

“So how accurate is Windows NTP synchronization in the end?” The answer depends on the era.

On Windows Server 2012 R2 / Windows 8.1 and earlier, w32time’s design goal was to provide accuracy sufficient for the requirements of Kerberos authentication (five minutes by default) and “roughly accurate time” within a single forest; tighter accuracy requirements are explicitly stated to be outside the design specification and unsupported.⁴ In other words, it is a world where “accurate to within a second or so” is working as designed.

On Windows Server 2016 / Windows 10 1607 and later, the algorithms were improved and the clock update frequency was raised substantially by default (for example, servers went from adjusting the clock once an hour to once a second).³ As a result, 1 second, 50 ms and 1 ms accuracy are now defined as support boundaries when the conditions are met. The principal conditions for 1 ms are as follows — and conversely, you must not expect 1 ms in an environment that does not meet them.⁴

• An NTP hierarchy topped by an accurate, stable Stratum 1 time source (such as a GPS clock), with every Windows machine along the path configured for high accuracy
• Network latency to the time source below 0.1 ms, and within Stratum 5 and 4 hops of the time source
• CPU utilization at each level of the hierarchy (daily average) at or below 80% (including the host in a virtualized environment)

It is also stated that with a remote internet time source such as time.windows.com, 1 ms accuracy cannot be expected, because of path asymmetry and congestion.⁷ As a practical rule of thumb, it is safest to think in three tiers: “workgroup defaults = seconds to tens of seconds of drift”, “a properly configured internal NTP sync = tens of milliseconds to within a second”, and “a purpose-built time source and design = millisecond class”. If your device integration needs millisecond-level ordering, you should not lean on time synchronization at all — lean instead, as described below, on a design that measures with a single machine’s clock.

5. Time on Virtual Machines — The Double Relationship Between the Hyper-V Time Synchronization Integration Service and NTP

Time on a virtual machine gets tangled more easily than on physical hardware. The reason is simple: there are two things offering it the time. Windows in a Hyper-V guest has both the Hyper-V Time Synchronization Integration Service (the VMICTimeSync provider), which takes time from the host, and the ordinary NTP client — and Windows picks “the better one” using Stratum, root delay, root dispersion and offset, in that order.⁷

Windows Server 2016 improved this mechanism considerably. The initial time at VM start and restore became accurate, samples corrected for interrupt latency began to be handed to w32time, and accuracy of around 10 µs relative to the host can be maintained. The Stratum the host reports to the guest also became a value that reflects reality (“host Stratum + 1”), and domain-joined 2016-or-later guests now choose the most accurate clock rather than deferring to the host.³

On the other hand, when running a Windows Server 2012 R2 or earlier guest in a domain, the Hyper-V time synchronization provider can disrupt domain time synchronization, so Microsoft’s guidance is to disable the provider.³

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t REG_DWORD /d 0 /f
net stop w32time && net start w32time

Azure VMs are covered as well, and the gist is: “for domain-joined VMs (especially virtualized DCs), disable TimeSync and rely solely on the domain hierarchy; for standalone non-domain VMs, leave host synchronization as the default”.³ The thinking is the same for third-party hypervisors (VMware and others), where disabling the host’s time synchronization feature is recommended for domain-joined guests.³ If the symptom is “NTP and host synchronization taking turns pulling the clock, so log times wander back and forth”, suspect this double relationship. One more operational caution: after restoring a VM from a saved state or immediately following a live migration, correction begins from a badly drifted state, so treat log times right after a restore as particularly untrustworthy.

6. Designing the Business System — Build on the Assumption That Time Drifts and Goes Backwards

Everything so far has been the infrastructure side, but no matter how well you arrange time synchronization, drift never reaches zero. Whoever builds the device integration software designs logging and time measurement on the assumption that time drifts, and sometimes goes backwards.

The first principle is to record log timestamps in UTC. Recording local time lets time zones, daylight saving and per-machine configuration differences get in the way of reconciliation (this topic is covered in detail in “Date, Time, and Timezones in Business Apps”). The second principle is to use different clocks for “when did it happen” and “how long did it take”.

// [Pitfall] Measuring elapsed time with the system clock
// If w32time applies a step correction, this difference can be longer or shorter
// than reality, or even negative
var start = DateTime.UtcNow;
ExecuteInspection();
var elapsed = DateTime.UtcNow - start;   // using this for a timeout check will misfire

// [Standard practice] Measure elapsed time with Stopwatch (a monotonic clock)
long t0 = Stopwatch.GetTimestamp();
ExecuteInspection();
TimeSpan elapsed2 = Stopwatch.GetElapsedTime(t0);   // .NET 7 or later; before that, Stopwatch.StartNew()

Stopwatch is a class dedicated to measuring elapsed time by counting ticks from the high-resolution performance counter (the equivalent of QueryPerformanceCounter), and it is unaffected by corrections to the system clock.⁵ DateTime.UtcNow, by contrast, is the system clock itself, and its resolution depends on the system timer (roughly 0.5 to 15 ms).⁶ Timeout checks, retry intervals, performance measurement, device response times — anything that deals with “duration” belongs on the Stopwatch side.

Write both into the log. Keeping a wall clock (UTC) value paired with a monotonic one lets you reconstruct ordering and intervals afterwards, even across an interval that spans an NTP step correction.

public sealed class OpLog
{
    private static readonly long _baseTimestamp = Stopwatch.GetTimestamp();
    private static long _seq;

    public static void Write(string message)
    {
        long seq = Interlocked.Increment(ref _seq);
        // UTC time (when it happened) + monotonic ms since startup (ordering and intervals)
        // + sequence number (ordering within the same timestamp)
        var line = $"{DateTime.UtcNow:yyyy-MM-dd'T'HH:mm:ss.fff'Z'}\t" +
                   $"{Stopwatch.GetElapsedTime(_baseTimestamp).TotalMilliseconds:F1}\t" +
                   $"{seq}\t{message}";
        // ... write out to file/ETW
    }
}

For reconciling logs across multiple machines and devices, add two more things. The first is to record the offset against the other party’s clock periodically. Devices that keep their own clocks, such as cameras and PLCs, can usually have their time read over the communication protocol, so log “the difference between the PC’s UTC time and the device time” at application startup and on a schedule (hourly, say). This is the device-side equivalent of w32tm /stripchart, and it lets you reconcile mechanically after a failure: “for this period, read the device log timestamps with a +12.3 second correction applied”. The second is to align the time base of your own logs with that of the event log and ETW records (see “An Introduction to Windows Event Log and ETW”). For crash-evidence design (“Designing Windows Apps to Leave Logs and Dumps When They Crash”) and for network-induced failure investigation such as a camera communication drop (“Why TCP Retransmissions Stall Industrial Camera Communication”), whether the time bases line up changes investigation time by an order of magnitude.

On an offline factory LAN (no internet connection), time.windows.com is unreachable, so the standard approach is to stand up a local NTP server on the LAN and align every device to it. A GPS clock is ideal, but even without one, if you can reach a state where “the absolute time may be somewhat off, but every device is aligned to the same reference”, you have achieved essentially all of what log reconciliation needs. On the reference server, also consider tuning LocalClockDispersion, which determines the accuracy it claims for itself while it cannot synchronize externally.²

7. Decision Table by Environment

8. Summary

• Windows time is managed by w32time: hierarchical synchronization topped by the PDC emulator in a domain, and low-frequency synchronization with time.windows.com by default in a workgroup. Drift of tens of seconds is not a fault — it is the consequence of the default values.
• Investigation starts with w32tm /query /status to check the source and last sync time, and w32tm /stripchart to measure the actual offset against a peer. Use /config /manualpeerlist to specify the source explicitly and /resync to apply it immediately.
• w32time corrects small offsets by slewing and large offsets by stepping. Remember that the system clock can jump backwards, and that nothing is corrected at all once the limits are exceeded.
• Historically, the accuracy goal for the default configuration was “enough for Kerberos’s five minutes”. Millisecond-class accuracy arrived with Windows Server 2016 and is supported only when the conditions on time source, latency, hop count and CPU load are met.
• Virtual machines have two sources: host synchronization and NTP. As a rule, domain-joined VMs should rely solely on domain synchronization (disabling VMICTimeProvider on older guest OSes), and standalone VMs should stay on host synchronization.
• On the application side: UTC for timestamps, Stopwatch for elapsed time, and a periodic record of the offset against the device’s own clock. Those three things are what get you out of failure investigations where “we can’t tell which came first”.

Related Articles

• Date, Time, and Timezones in Business Apps — From DateTime Pitfalls to the UTC-Storage Principle and Test Design
• Designing Windows Apps to Leave Logs and Dumps When They Crash
• An Introduction to Windows Event Log and ETW — Putting Your Business App’s Logs on the OS’s Standard Mechanisms
• Why TCP Retransmissions Stall Industrial Camera Communication, and How to Isolate Them
• When Task Scheduler Tasks Don’t Run or Exit with 0x1 — Isolating the Cause and Designing for Reliable Operation
• Japanese Era Dates, Public Holidays, and Closing-Date Processing in Business Apps — Era-Resilient Design, JapaneseCalendar, and Business-Day Calculations in Practice

Related Consulting Areas

KomuraSoft LLC takes on investigations of the kind where “the log times on the device and the PC don’t agree, so we can’t establish the order of events in a failure”, time synchronization design for factory LANs and device-integrated environments, and the development and improvement of device integration software — including defects around timeouts and time measurement.

• Bug Investigation & Root Cause Analysis
• Technical Consulting & Design Review
• Soft Real-Time Windows App Development
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

The logs on my PC and the logs on the device don't line up. What should I check first?

Start by running w32tm /query /status on the PC and checking "Source" (what it is synchronizing with) and "Last Successful Sync Time". If the source is Local CMOS Clock, or the last sync was days ago, that PC is effectively not synchronized with anything. Next, use w32tm /stripchart /computer:<peer> /dataonly to measure the actual offset against the peer (a server, or the device's NTP port) so you have a number for who is off and by how much. If the device keeps its own clock, read the device time from its settings screen or over the wire and record the difference from the PC's time — that record is also what lets you reconcile historical logs later.

How often does a Windows machine in a workgroup actually synchronize its time?

A Windows machine that is not joined to a domain synchronizes with time.windows.com by default, but the frequency is set very low. The registry default for SpecialPollInterval is 604,800 seconds (one week) in a standalone configuration, and even a Windows 10 client only polls about once a day. Internal PC clocks routinely drift by seconds to tens of seconds per day, so at that frequency you cannot expect accuracy good enough to reconcile business logs. Where log time accuracy matters, the standard move is to point the machine at an internal NTP server with w32tm /config /manualpeerlist and shorten SpecialPollInterval.

Should a virtual machine on Hyper-V take its time from the host or from NTP?

A Hyper-V guest has two time providers — the Hyper-V Time Synchronization Integration Service (VMICTimeSync) and the NTP client — and Windows picks the better of the two using criteria such as Stratum. For a domain-joined guest the rule is to synchronize with the domain hierarchy (a DC), and with Windows Server 2016 or later on both host and guest the two have been improved so they can coexist. If you are running a Windows Server 2012 R2 or earlier guest in a domain, Microsoft's guidance is to disable VMICTimeProvider and rely solely on domain synchronization. For a standalone VM in a workgroup, leaving the default host synchronization in place is the simple, reliable choice.

What happens in a domain environment if the time drifts badly?

Kerberos, which Active Directory uses for authentication, requires by default that client and server clocks agree to within five minutes. Beyond that, authentication fails and basic domain functions — access to shared folders, Group Policy application and so on — stop working. Domain-joined PCs synchronize by default with a DC, and ultimately through a hierarchy topped by the PDC emulator in the forest root, so it is unusual to drift that far. The flip side is that if the PDC emulator itself is not synchronized with an accurate external time source, the entire domain will be "consistently wrong together" — which is why checking the configuration at the top of the hierarchy matters.

Why shouldn't I use DateTime.UtcNow to measure elapsed time?

Because DateTime.UtcNow reads the system clock, and therefore takes the full brunt of w32time's corrections. When the offset is large, w32time does not slew gradually — it steps, setting the clock directly, and the time can jump either forwards or backwards. That means an elapsed time computed by subtracting two UtcNow values can come out longer than reality, shorter than reality, or negative. For elapsed time and timeouts, use Stopwatch (or Stopwatch.GetTimestamp), which increases monotonically and independently of the system clock, and treat UtcNow strictly as a record of "when did this happen".

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.