2

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: Event log timestamps
(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:
Task Manager process list

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):
Process Explorer

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: Security Log

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

  • It sounds like your attempts to "avoid" DST issues are probably the cause. As long as the Windows timezone data is accurate, you should either let it handle DST, or run it in UTC. – Michael Hampton Apr 18 '18 at 2:47
  • @MichaelHampton DST is unacceptable. UTC would be a big overhaul. I should mention that there are roughly 30 other similar systems not exhibiting this problem. – Ian Apr 18 '18 at 3:14
  • 1
    @Appleoddity yep, it does seem that way (setting aside the fact that host time sync is disabled). I've just double-checked, and the other system we've seen it happening on is also a Parallels VM. Except, the way Parallels changes the guest OS time is using Parallels Tools. I would have expected the Parallels Tools process to be the one changing the time, not the System process. I was hoping I could intelligently determine the offender, rather than blindly disabling things and waiting for an hour each time. – Ian Apr 18 '18 at 5:51
  • 1
    Well, you’ve done a good job, but sometimes it just takes trial and error. You can find out pretty quickly if it’s a running process by disabling most everything and waiting an hour. At least you know if you’re wasting your time. I think it’s your vm host. But the idea about the tools is good. Maybe it’s a driver doing this, maybe the parallels drivers, and that isn’t going to show up in the things you’ve looked at, I don’t think. You could try uninstalling the drivers for now. – Appleoddity Apr 18 '18 at 5:55
  • 1
    @Appleoddity Because I had already disabled VM time sync, and because the changes weren't initiated by the Parallels Tools process (it actually runs 3), I had largely discounted that. Now you've made me look at it more closely, and I think you're right. I've found a total of 4 systems exhibiting this problem now, the only 4 we have running Parallels (most are running VMWare). I'm killing and disabling the Parallels services, just waiting for the next "hour" tick in 15 minutes to confirm. Then I can take it up with Parallels. – Ian Apr 18 '18 at 6:21
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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.