Find windows process that is changing time back 1 hour

Question

I have a windows machine which will periodically change the system time, for reasons unknown. It appears to happen every hour.

This windows machine is a virtual machine (Parallels Desktop 9, Win7 guest, OSX host). It has an NTP service (NetTime) running that promptly corrects the error, but in those brief few seconds between change and correction, it causes problems.

I have checked:

• VM time synchronisation is disabled
• Windows "Internet Time" is disabled
• Windows Time service is disabled
• I only have a single NTP client running, updating every 15 minutes

There is a complication. We run an overnight astronomy service. In order to avoid issues arising from automatic DST changes, we disable automatic DST changes, and manually set the machine timezone later in the day to a zone with the correct offset. Eg in Spain it is DST right now. Standard time is UTC+1, DST is UTC+2. The morning after DST changes we set the machine timezone to Greece UTC+2. Host machine is configured normally (correct timezone, automatic DST changes). The complication is that the clock changes back to the current time at UTC+1 (pre-DST time).

SOME process is changing this. Possibly it has it's own timezone setting. But I have been unable to track it down. The changes are logged in the System Log. There are two key entries: where the time is set incorrectly, and when it is corrected:
(Full disclosure, the event log is filtered by Event ID = 1, but the other events appear meaningless).

It's interesting how regular these occur (every hour, to the second). What's more interesting is that these are hours of uptime. I can watch the system Up Time in Task Manager, and when it ticks over the hour, the clock changes.

Also interesting is looking at the event details:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
    - <System> 
        <Provider Name="Microsoft-Windows-Kernel-General" Guid="{GUID}" /> 
        <EventID>1</EventID> 
        <Version>0</Version> 
        <Level>4</Level> 
        <Task>0</Task> 
        <Opcode>0</Opcode> 
        <Keywords>0x8000000000000010</Keywords> 
        <TimeCreated SystemTime="2018-04-18T00:31:28.500000000Z" /> 
        <EventRecordID>500706</EventRecordID> 
        <Correlation /> 
        <Execution ProcessID="4" ThreadID="56" /> 
        <Channel>System</Channel> 
        <Computer>T07-VM-GUEST</Computer> 
        <Security UserID="SID" /> 
    </System> 
    - <EventData> 
        <Data Name="NewTime">2018-04-18T00:31:28.500000000Z</Data> 
        <Data Name="OldTime">2018-04-18T01:31:28.861800000Z</Data> 
    </EventData> 
</Event>

We can see this event changes from 01:31 to 00:31 (UTC times, 03:31 to 02:31 local as seen in event log). What is particularly interesting is this line:

<Execution ProcessID="4" ThreadID="56" /> 

PID 4 is the System process:

Using ProcessExplorer I can inspect the System process (PID 4) and I can see some details on ThreadId 56 (assuming they don't get recycled and I'm looking at the correct one):

But it's all gibberish to me. The only meaningful thing I can see here is the Start Time, and how it relates to the clock change event times (as I said above, every hour in sync with Uptime).

This answer talks about finding time changes in the Security Log, and all of the changes initiated by the NetTime service are in there. But the problematic changes are suspiciously missing:

Am I correct in my analysis, and if so, why is the System Process changing my system clock every hour?

Answer 1

Ok, as all the worst types of problems do, this one had two parts.

1. Windows updates the system time every hour to the hardware clock. (Note it also does this on boot, which sped up testing)
2. Parallels was virtualising the hardware clock incorrectly. I have to say I'm using an old version of Parallels (PD9), I would hope they have fixed this by now.

I haven't found any definitive statement about this, but I've seen plenty of people in my shoes confirming the same thing: every hour Windows reads the Real Time Clock (RTC, or the hardware clock in the BIOS) and re-syncing with it. See references: #1, #2, #3, #4.

Obviously most of these are to do with faulty RTC, flat BIOS batteries, or dual-booting with a *nix OS (which stores UTC in the RTC, not local time). But the fact remains that Windows will do this every hour. I have not found a way to disable this yet.

In addition, Parallels doesn't keep a hardware clock per-se, instead it keeps an offset (from System time) in the VM config file. The problem is that this offset doesn't correctly take into account DST. So for example I have a host Mac in Madrid, Spain which is normally UTC+1, but currently in Summer Time it is UTC+2. When I set the time in my guest machine, Parallels computes the difference between my guest time and my host timezone WITHOUT DST.

Let's do an example:
Current time is UTC 00:00.
Madrid standard time would be UTC+1, so 01:00. Except it's currently DST, UTC+2, 02:00. I set my guest machine to 02:00, Windows tries to write this to RTC, Parallels computes the difference between my guest time and Madrid Standard (01:00), and saves <TimeShift>-3600</TimeShift> into the config file (file is only updated on reboot, I imagine this variable is tracked in memory during runtime). So every time Windows reads the RTC (Parallels reads the host system time), it thinks the RTC is set to HostTime-3600s (-1 hr) and updates the time.

I know my guest machine has a complicated setup (manually set to Cairo to find a timezone without DST), I thought I'd give Parallels the benefit of the doubt and see if it works correctly with both guest and host set to the correct timezone (Madrid with DST). Nope, it still screws up.

Solution:
I can't find a way to disable Windows from reading the RTC every hour, so for the time being I've forced the host machine to use a timezone that doesn't use DST (eg Cairo, UTC+2). This works. When I save my guest time to 02:00, and Cairo time (UTC+2) is 02:00, Parallels saves <TimeShift>0</TimeShift>.

Ugly.

Answer 2

There are two times available to software, the System Time and Local Time. System time should not be updated regardless of the DST setting. local Time is what is adjusted. If this is not the case then there is a programming error in your OS or more likely the application. it may be that the application is using e.g. GetLocalTime() when it should be using GetSystemTime() and the UI is erroneously stating that it is system time.

Answer 3

I've been struggling with this exact system event for days. Numerous attempts of disabling or configuring the time synchronization services failed. I ended up finding a workaround to prevent the system from adjusting the system time every 3600 Seconds.

Win32 API offers a SetSystemTime function to set the system time to any desired time. PowerShell offers a more convenient function Set-Date that wraps the API call. By calling Set-Date -Adjust 0 the system time stays unchanged, but the system seams happy. The ugly part, the call needs to be repeated within every 3600 Seconds, to prevent the system event continuously. Hence, I run a PowerShell script to register a scheduled task that is triggered every 59 Minutes:

$taskName = "Mock System Time Synchronization"
$taskDescription = "This task prevents the system to synchronize the system time with the hardware clock every 3600 seconds."

$startTime = (Get-Date) + (New-TimeSpan -Minutes 1)
$action = New-ScheduledTaskAction -Execute 'Powershell.exe' -Argument '-WindowStyle Hidden -command "& Set-Date -Adjust 0"'
$trigger =  New-ScheduledTaskTrigger -Once -At $startTime -RepetitionInterval (New-TimeSpan -Minutes 59)

Register-ScheduledTask -Action $action -Trigger $trigger -TaskName $taskName -Description $taskDescription -User "System"