[ntp:questions] NTP client with ability to write Windows NT system time to hardware clock?

Brolin Empey brolin at brolin.be
Sat Dec 18 22:07:48 UTC 2010

Martin Burnicki wrote:
> Brolin,
> Brolin Empey wrote:
>> I run Windows 7 Professional IA-32 with RealTimeIsUniversal=1 on
>> brolin-V13, my Dell Vostro V13 laptop. This means brolin-V13?s hardware
>> clock (RTC) runs in UTC, as it should, instead of the local time zone,
>> as Microsoft still uses for the completely illogical default
>> configuration.  RealTimeIsUniversal=1 is /finally/ fixed and fully
>> working beginning in Windows Vista SP2 + Windows 7, but there is still a
>> problem:  When RealTimeIsUniversal=0, which is also used when the
>> RealTimeIsUniversal key does not exist, Windows 7 writes the Windows NT
>> system time to the hardware clock during the shut down process.  When
>> RealTimeIsUniversal=1, though, the Windows NT system time is never
>> written to the hardware clock.
> Hm, this sounds like a Windows bug ...

No, it is by design. :(

>> Consequently, I have to boot Ubuntu from
>> a USB flash drive (brolin-V13 has no optical disc drive (ODD).), then
>> use ntpdate-debian + hwclock to synchronise the Linux system clock with
>> an NTP server on the Internet, then write the
>> sufficiently-accurate-for-me Linux system time to the hardware clock so
>> Windows 7 will set the Windows NT system clock from the accurate time in
>> the hardware clock.  After some time (at least 1 week, not sure.),
>> though, my hardware clock is approximately 2 minutes behind the correct
>> time from an NTP server, but Windows 7 never writes the Windows NT
>> system time to the hardware clock when RealTimeIsUniversal=1, so I have
>> to use my Ubuntu USB flash drive again.
> Do you need correct time for the on-board RTC for a special application?

No, but I still want my clocks to have accurate time.

> As
> far as I know this is only used to initialize the Windows system time when
> Windows starts up, so your system time may be wrong until ntpd has a chance
> to correct it, i.e. it can reach an NTP server.

I am using Microsoft’s w32time service, not ntpd.

I have configured the w32time service to start automatically, but it 
does not seem to start automatically, so my system time is approximately 
2 minutes behind until I run "net start w32time && w32tm /resync" in an 
elevated (with administrative privileges) cmd.exe session.

>> I know the proper solution is
>> to get Microsoft to change Windows 7 so it can write the Windows NT
>> system time to the hardware clock even when RealTimeIsUniversal=1, but
>> that has not yet happened.  I have at least asked a Microsoft employee
>> about it, though, so they know users (well, at least 1 user. :)) want
>> the feature.  I can use w32time to force a synchronisation, but then I
>> have to do that every time I boot Windows 7.  brolin-V13 travels with me
>> between home and work, so it is not always running.  Maybe this causes
>> the hardware clock to fall behind, but I do not think I can prevent
>> having to shut down and boot brolin-V13 on a daily basis.  Since I do
>> not know if Microsoft will ever enable Windows 7 to write the Windows NT
>> system time to the hardware clock when RealTimeIsUniversal=1, the next
>> best solution is probably to write a hwclock.exe application for Windows
>> NT, but I am hoping someone has already implemented this functionality
>> in an application such as an NTP client.  Googling ?hwclock.exe? returns
>> lots of noise because some malware uses this file name, but I have not
>> found any real hwclock.exe equivalent to hwclock used on Linux.
> During normal operation the ntpd service should not call the Windows
> SetSystemTime() API since doing so causes a time offset offset to be
> applied to the system time.
> As far as I know ntpd calls SetSystemTime() only when the Windows system
> time needs to be stepped anyway, or when the ntpd service shuts down.
> Calling SetSystemTime() should also set the HW clock. If this doesn't happen
> then the Windows bug mentioned above is probably inside that Windows API
> call.

Again, I am using w32time, not ntpd.  The behaviour you call a bug is by 
design.  I looked up SetSystemTime on MSDN but could not find anything 
even suggesting SetSystemTime is supposed to update the hardware clock. 
  I actually could not find any official documentation on how to set the 
hardware clock from a userspace application on Windows NT, but I have 
found how (see below).

>> So, is there an NTP client or any other application for Windows NT which
>> can write the Windows NT system time to the hardware clock so I do not
>> have to write hwclock.exe for Windows NT?
> A proper solution would indeed be to write a program which just reads the
> current system time without changing it, and then writes the system time to
> the HW clock. However, this requires a devce driver to be able to write to
> the CMOS chip. I'm not sure whether there is a documented or undocumented
> software interface to the Windows kernel to call Windows' built-in driver.

The HalSetRealTimeClock function in the Windows NT kernel’s HAL needs to 
be called but, AFAICT, even a device driver cannot call HalSetRealTimeClock.

I actually downloaded and installed Microsoft’s Windows Driver Kit 
(WDK), formerly the Windows NT DDK, and searched the documentation, but 
could not find anything about HalSetRealTimeClock.  I do not know if 
calling HAL functions from outside of the HAL is even officially 
supported or was considered in the design of Windows NT.

I have found discussions mentioning use of HalSetRealTimeClock (+ 
HalQueryRealTimeClock) but cannot even find any occurrences of 
“realtimeclock” in C:\WinDDK\7600.16385.1\ .  This suggests to me that 
Microsoft has changed the set of HAL functions exported/available to 
device drivers.  I could try downloading archived versions of the NT DDK 
to check, but I do not think that is necessary after some more Googling:


(The .htm instead of .html is so appropriate for a site about Micros~1 
software. ;))


This NDK looks like what I need, but it also looks incomplete:

1. readme.txt references ndk.txt , but ndk.txt is missing from both the 
svn repository + ndk.zip .  I reported this issue:


2. The project describes itself as “A set of headers, libraries and 
sample source code for writing Windows Native Applications”, but only 
headers are included in the svn repository + ndk.zip .

I also found 
from chapter 6 of "Undocumented Windows 2000 Secrets", but it is from 
2000-08-27 and uses ntoskrnl.exe (uniprocessor) instead of ntkrnlpa.exe 
(multiprocessor), so I doubt it is still useful on Windows 7 with a 
multiprocessor HAL.

And yes, I know this thread is probably off-topic for this group by now.

> Maybe a workaround would be the usual way to let Windows write the local
> time to the RTC, and then tell your Linux system the RTC runs in local
> time. This should only cause a problem if you whut down Windows before a
> DST changes, and boot Linux the next time after DST has changed.

Running my hardware clock in the local time zone is *not* an acceptable 
workaround for me. :)  I used to do that, but had problems so I decided 
my hardware clock *must* run in UTC.

I actually had a PC (cannon, my tower PC at work) which ran only Linux 
but with the hardware clock in the local time zone.  cannon is usually 
always running, except when the power is out, cannon stays off until I 
manually press the soft (ATX) power switch on the front of the case to 
power on again the next time I am at work after the power outage.

A year or two ago, the power was out during the weekend when DST 
changed.  I know the Linux kernel can be configured to frequently 
(11-minute mode, IIRC) write the system time to the hardware clock, but 
I did not have that enabled, so the system time is written to the 
hardware clock only when Linux shuts down.

So, cannon was running during the weekend while I was not at work, DST 
changed, then cannon lost power and remained off until I booted it when 
I returned to work at the beginning of the next week.  cannon’s system 
time was then incorrect because the system time was set from the 
hardware clock, which did not get updated after the DST change.

That was when I finally decided my hardware clock *must* run in UTC 
because trying to daylight switch the hardware clock twice per year is 
completely illogical /and/ actually affects me in my practical usage.

More information about the questions mailing list