ERROR_TIME_SKEW (0X00000576) – Windows Time Sync Fix

1. The 5-Minute Clock Drift (Most Common Cause)

This error pops up when your computer's internal clock is off from the server's by more than 5 minutes. Kerberos authentication won't tolerate that gap. You'll see it when trying to log into a domain, access a shared drive, or connect to a VPN.

Here's the quick fix that works 90% of the time:

1. Press Windows Key + R, type cmd, right-click Command Prompt and select Run as administrator.
2. Type this command and press Enter: w32tm /resync
3. After running it, you should see "The command completed successfully". If you get "The computer did not resync because no time data was available", keep reading.

If the resync worked, run w32tm /query /status and check the Source field. It should show a time server like time.windows.com or your domain controller's name. If the source is Local CMOS Clock, that's a problem. You need to set an NTP peer.

Force a manual NTP server

1. Open Command Prompt as administrator again.
2. Run these three commands one at a time:

net stop w32time
w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update
net start w32time

After starting the service, run w32tm /resync again. You should see success. Then check the time—it'll snap right to the correct value.

Why this works: The default Windows Time service is flaky. It depends on how your hardware battery-backed clock behaves. Some motherboards drift badly, especially older ones. Pointing it directly to pool.ntp.org forces a clean sync every time.

2. Hyper-V or VMware Virtual Machine Clock Skew

If you're running a VM in Hyper-V, VMware, or VirtualBox, time skew is a whole different animal. Virtual machines don't have their own hardware clock—they borrow time from the host. And the host can drift, especially if it's been running for weeks without a reboot.

Here's the specific trigger: You pause a VM, resume it hours later, and Kerberos rejects the connection because the VM's time didn't update. The error code 0X00000576 shows up immediately.

Fix for Hyper-V VMs

1. On the Hyper-V host, right-click the VM and select Settings.
2. Go to Integration Services.
3. Make sure Time synchronization is checked. If it's already checked, uncheck it, click Apply, then recheck it. This resets the sync channel.
4. Inside the guest VM, open an admin Command Prompt and run w32tm /resync. It should update immediately.

For VMware: Install VMware Tools on the guest. That includes the time sync driver. If it's already installed, go to the VM's Edit Settings > VM Options > VMware Tools and enable Synchronize guest time with host.

One thing that trips people up: Turning off time sync inside the guest OS itself. In Windows, if you disable the Windows Time service, the host can't sync with it. So make sure w32time is set to Automatic and running.

3. Domain Controller Time Drift (PDC Emulator Role)

In a domain environment, the PDC emulator (Primary Domain Controller) is the time boss. Every other machine syncs to it. If the PDC emulator's clock is wrong, every single client will eventually show ERROR_TIME_SKEW.

Here's the tell: Users in one office get this error, but users in another office don't. Or it happens only after a power outage.

Check which DC holds the PDC emulator role

1. Log into any domain controller.
2. Open an admin Command Prompt and run: netdom query fsmo
3. Look for the line that says PDC. That's the server you need to fix.

Fix the PDC emulator's time

1. On the PDC server, open admin Command Prompt.
2. Set it to sync with an external NTP source:

w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync

The ,0x8 part tells Windows to use the time server as a special NTP provider. Don't skip it. After resyncing, the PDC's time should update within a few seconds.

Then force other domain controllers to resync by running w32tm /resync /nowait on each one. Clients will pick up the correct time within 15-30 minutes naturally, or you can force a resync on a client machine with w32tm /resync.

One gotcha: If your domain is isolated from the internet (air-gapped), you can't reach pool.ntp.org. In that case, set the PDC emulator to sync with its own CMOS clock: w32tm /config /syncfromflags:domhier /update. But make sure the PDC's hardware clock is accurate—replace the CMOS battery if it's old.

Quick-Reference Summary Table

Final tip: Don't overthink it

I've seen people rebuild servers over this error. Don't. Start with w32tm /resync. If that fails, check if you're in a VM and fix the integration services. Move up to the domain controller only if the problem is widespread. Nine times out of ten, it's a dead CMOS battery or a paused VM.

If you're still stuck after these steps, check the System event log for event ID 37 (time source error) or 58 (time adjustment rejected). Those logs tell you exactly which time server is failing. Then you can trace it from there.