time /s leaks handles

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
I've seen this with Tardis, D4, NIST tools, and TCC time /s. In each case
when I use the tool to synchronize my computer time, the system process (PID
4) gets another handle to
HKLM\System\ControlSet001\Control\TimeZoneInformation. I'm using
sysinternals' handle and procexp to verify.

I know it happens with tools that are entirely unrelated to TCC, but hoped
that perhaps Rex or somebody could suggest why my system is losing these
handles. The handles remain even after terminating all possible processes
using procexp.

TCC 11.00.48 Windows XP [Version 5.1.2600]
TCC Build 48 Windows XP Build 2600 Service Pack 3

Also, what calls are necessary to get another system's time and synchronize?
I haven't seen the calls to get another system time yet.

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
#2
On Wed, 02 Jun 2010 16:09:44 -0400, Jim Cook <> wrote:

|I've seen this with Tardis, D4, NIST tools, and TCC time /s. In each case
|when I use the tool to synchronize my computer time, the system process (PID
|4) gets another handle to
|HKLM\System\ControlSet001\Control\TimeZoneInformation. I'm using
|sysinternals' handle and procexp to verify.

That doesn't happen with my TIMESYNC plugin (SYSUTILS); ProcessExplorer doesn't
even blink. And my W32TM.DLL, a replacement for W32TIME.DLL (Windows Time
Service), uses the same routine (every day for 7 years ... 24 days since reboot)
and there are no open handles to that key. [Maybe I'm doing it wrong!] :-)

|Also, what calls are necessary to get another system's time and synchronize?
|I haven't seen the calls to get another system time yet.

The time-related functions used by TIMESYNC are these (all else is Winsock and
number-crunching).

SystemTimeToFileTime
GetSystemTimeAsFileTime
FileTimeToSystemTime
SetSystemTime

There's no need for any TZ info since the whole transaction and the setting of
the clock are in UTC.

P.S. W32TM works pretty well. In addition to sync'ing the time, it adjusts the
system's "System Time Adjustment" (how many ticks the system thinks a second is)
throughout the day to keep the clock accurate. It learns from experience and
adapts. It's average daily adjustment over the 1.5 year life of this computer
is -0.029 sec (standard deviation .318 sec). My computer's clock is nowhere
near that accurate.
--
- Vince
 
#3
Using your timesync, I also see the leaked handle on my machine. I'm sure
there's something in my system doing it, but can not figure out what it
might be. Again, the leaked handles are in PID:4, not any other running
process.

I thought there was a get-other-machine-time call I was missing. The normal
SetSystemTime and family I'm plenty familiar with.

I may fiddle with SetSystemTime myself and see if handles leak just from
that.

On Wed, Jun 2, 2010 at 3:07 PM, vefatica <> wrote:


> On Wed, 02 Jun 2010 16:09:44 -0400, Jim Cook <> wrote:
>
> |I've seen this with Tardis, D4, NIST tools, and TCC time /s. In each case
> |when I use the tool to synchronize my computer time, the system process
> (PID
> |4) gets another handle to
> |HKLM\System\ControlSet001\Control\TimeZoneInformation. I'm using
> |sysinternals' handle and procexp to verify.
>
> That doesn't happen with my TIMESYNC plugin (SYSUTILS); ProcessExplorer
> doesn't
> even blink. And my W32TM.DLL, a replacement for W32TIME.DLL (Windows Time
> Service), uses the same routine (every day for 7 years ... 24 days since
> reboot)
> and there are no open handles to that key. [Maybe I'm doing it wrong!]
> :-)
>
> |Also, what calls are necessary to get another system's time and
> synchronize?
> |I haven't seen the calls to get another system time yet.
>
> The time-related functions used by TIMESYNC are these (all else is Winsock
> and
> number-crunching).
>
> SystemTimeToFileTime
> GetSystemTimeAsFileTime
> FileTimeToSystemTime
> SetSystemTime
>
> There's no need for any TZ info since the whole transaction and the setting
> of
> the clock are in UTC.
>
> P.S. W32TM works pretty well. In addition to sync'ing the time, it adjusts
> the
> system's "System Time Adjustment" (how many ticks the system thinks a
> second is)
> throughout the day to keep the clock accurate. It learns from experience
> and
> adapts. It's average daily adjustment over the 1.5 year life of this
> computer
> is -0.029 sec (standard deviation .318 sec). My computer's clock is
> nowhere
> near that accurate.
> --
> - Vince
>
>
>
>
>


--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
#4
I believe I have proven that SetSystemTime leaks a handle in PID:4 every
time I call it, on my machine.

On Wed, Jun 2, 2010 at 3:26 PM, Jim Cook <> wrote:


> Using your timesync, I also see the leaked handle on my machine. I'm sure
> there's something in my system doing it, but can not figure out what it
> might be. Again, the leaked handles are in PID:4, not any other running
> process.
>
> I thought there was a get-other-machine-time call I was missing. The normal
> SetSystemTime and family I'm plenty familiar with.
>
> I may fiddle with SetSystemTime myself and see if handles leak just from
> that.
>
> On Wed, Jun 2, 2010 at 3:07 PM, vefatica <> wrote:
>
>
>
> ---Quote---
> > On Wed, 02 Jun 2010 16:09:44 -0400, Jim Cook <> wrote:
> >
> > |I've seen this with Tardis, D4, NIST tools, and TCC time /s. In each
> case
> > |when I use the tool to synchronize my computer time, the system process
> > (PID
> > |4) gets another handle to
> > |HKLM\System\ControlSet001\Control\TimeZoneInformation. I'm using
> > |sysinternals' handle and procexp to verify.
> >
> > That doesn't happen with my TIMESYNC plugin (SYSUTILS); ProcessExplorer
> > doesn't
> > even blink. And my W32TM.DLL, a replacement for W32TIME.DLL (Windows
> Time
> > Service), uses the same routine (every day for 7 years ... 24 days since
> > reboot)
> > and there are no open handles to that key. [Maybe I'm doing it wrong!]
> > :-)
> >
> > |Also, what calls are necessary to get another system's time and
> > synchronize?
> > |I haven't seen the calls to get another system time yet.
> >
> > The time-related functions used by TIMESYNC are these (all else is
> Winsock
> > and
> > number-crunching).
> >
> > SystemTimeToFileTime
> > GetSystemTimeAsFileTime
> > FileTimeToSystemTime
> > SetSystemTime
> >
> > There's no need for any TZ info since the whole transaction and the
> setting
> > of
> > the clock are in UTC.
> >
> > P.S. W32TM works pretty well. In addition to sync'ing the time, it
> adjusts
> > the
> > system's "System Time Adjustment" (how many ticks the system thinks a
> > second is)
> > throughout the day to keep the clock accurate. It learns from experience
> > and
> > adapts. It's average daily adjustment over the 1.5 year life of this
> > computer
> > is -0.029 sec (standard deviation .318 sec). My computer's clock is
> > nowhere
> > near that accurate.
> > --
> > - Vince
> >
> >
> >
> >
> >
> ---End Quote---
>
>
> --
> Jim Cook
> 2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
> Next year they're Monday.
>
>
>
>
>


--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
#5
In fact, this happens even in safe mode. A program consisting of
GetSystemTime / SetSystemTime only bleeds one handle per execution.

On Wed, Jun 2, 2010 at 3:46 PM, Jim Cook <> wrote:


> I believe I have proven that SetSystemTime leaks a handle in PID:4 every
> time I call it, on my machine.
>
> On Wed, Jun 2, 2010 at 3:26 PM, Jim Cook <> wrote:
>
>
>
> ---Quote---
> > Using your timesync, I also see the leaked handle on my machine. I'm sure
> > there's something in my system doing it, but can not figure out what it
> > might be. Again, the leaked handles are in PID:4, not any other running
> > process.
> >
> > I thought there was a get-other-machine-time call I was missing. The
> normal
> > SetSystemTime and family I'm plenty familiar with.
> >
> > I may fiddle with SetSystemTime myself and see if handles leak just from
> > that.
> >
> > On Wed, Jun 2, 2010 at 3:07 PM, vefatica <> wrote:
> >
> >
> >
> > ---Quote---
> > > On Wed, 02 Jun 2010 16:09:44 -0400, Jim Cook <> wrote:
> > >
> > > |I've seen this with Tardis, D4, NIST tools, and TCC time /s. In each
> > case
> > > |when I use the tool to synchronize my computer time, the system
> process
> > > (PID
> > > |4) gets another handle to
> > > |HKLM\System\ControlSet001\Control\TimeZoneInformation. I'm using
> > > |sysinternals' handle and procexp to verify.
> > >
> > > That doesn't happen with my TIMESYNC plugin (SYSUTILS); ProcessExplorer
> > > doesn't
> > > even blink. And my W32TM.DLL, a replacement for W32TIME.DLL (Windows
> > Time
> > > Service), uses the same routine (every day for 7 years ... 24 days
> since
> > > reboot)
> > > and there are no open handles to that key. [Maybe I'm doing it wrong!]
> > > :-)
> > >
> > > |Also, what calls are necessary to get another system's time and
> > > synchronize?
> > > |I haven't seen the calls to get another system time yet.
> > >
> > > The time-related functions used by TIMESYNC are these (all else is
> > Winsock
> > > and
> > > number-crunching).
> > >
> > > SystemTimeToFileTime
> > > GetSystemTimeAsFileTime
> > > FileTimeToSystemTime
> > > SetSystemTime
> > >
> > > There's no need for any TZ info since the whole transaction and the
> > setting
> > > of
> > > the clock are in UTC.
> > >
> > > P.S. W32TM works pretty well. In addition to sync'ing the time, it
> > adjusts
> > > the
> > > system's "System Time Adjustment" (how many ticks the system thinks a
> > > second is)
> > > throughout the day to keep the clock accurate. It learns from
> experience
> > > and
> > > adapts. It's average daily adjustment over the 1.5 year life of this
> > > computer
> > > is -0.029 sec (standard deviation .318 sec). My computer's clock is
> > > nowhere
> > > near that accurate.
> > > --
> > > - Vince
> > >
> > >
> > >
> > >
> > >
> > ---End Quote---
> >
> >
> > --
> > Jim Cook
> > 2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
> > Next year they're Monday.
> >
> >
> >
> >
> >
> ---End Quote---
>
>
> --
> Jim Cook
> 2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
> Next year they're Monday.
>
>
>
>
>


--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
#6
On Wed, 02 Jun 2010 19:25:32 -0400, Jim Cook <> wrote:

|In fact, this happens even in safe mode. A program consisting of
|GetSystemTime / SetSystemTime only bleeds one handle per execution.

Are you running w32time (Windows Time Service)? It could be (probably is)
getting notification of SetSystemTime() and doing something untoward.

I don't know if w32time runs in safe mode.
--
- Vince
 
#7
On Wed, 02 Jun 2010 19:25:32 -0400, Jim Cook <> wrote:

|In fact, this happens even in safe mode. A program consisting of
|GetSystemTime / SetSystemTime only bleeds one handle per execution.

Found this, which might be fun to play with. It's in W32TIME.DLL.

typedef int ( __stdcall* W32TimeSyncNow)( const wchar_t *pwszComputer,
unsigned int blocking, unsigned int flags);

Force a time sync with a network time server
Parameters:
- pwszComputer: the computer to sync the clock for,
NULL to sync the local computer.
- blocking: 0: to perform an asynchronous call (always returns 'ok')
1: perform a blocking call
- flags: probably a bitwise combination. Following combinations are tested:
0x03: just resync
0x06: redetect the network configuration and rediscover network
sources, than resync

return value:
0: update successful
1: The computer did not resync because no time data was available
2: The computer did not resync because only stale time data was
available
3: The computer did not resync because the time service was shutting
down
4: The computer did not resync because the required time change was
too big
any other value: standard Windows Error
--
- Vince
 
#8
I don't think W32TimeSyncNow is for NTP. Maybe it's for sync'ing within a
domain. This is all I could get out of it, having tried many combinations of
the two INT params.

g:\projects\w32ts\release> w32ts.exe
The RPC server is unavailable.


On Wed, 02 Jun 2010 20:50:57 -0400, vefatica <> wrote:

|On Wed, 02 Jun 2010 19:25:32 -0400, Jim Cook <> wrote:
|
||In fact, this happens even in safe mode. A program consisting of
||GetSystemTime / SetSystemTime only bleeds one handle per execution.
|
|Found this, which might be fun to play with. It's in W32TIME.DLL.
|
|typedef int ( __stdcall* W32TimeSyncNow)( const wchar_t *pwszComputer,
|unsigned int blocking, unsigned int flags);
|
|Force a time sync with a network time server
|Parameters:
|- pwszComputer: the computer to sync the clock for,
|NULL to sync the local computer.
|- blocking: 0: to perform an asynchronous call (always returns 'ok')
|1: perform a blocking call
|- flags: probably a bitwise combination. Following combinations are tested:
|0x03: just resync
|0x06: redetect the network configuration and rediscover network
|sources, than resync
|
|return value:
|0: update successful
|1: The computer did not resync because no time data was available
|2: The computer did not resync because only stale time data was
|available
|3: The computer did not resync because the time service was shutting
|down
|4: The computer did not resync because the required time change was
|too big
|any other value: standard Windows Error
--
- Vince
 
#9
That's the message I get when trying to use the Windows time service.

On Wed, Jun 2, 2010 at 9:42 PM, vefatica <> wrote:


> I don't think W32TimeSyncNow is for NTP. Maybe it's for sync'ing within a
> domain. This is all I could get out of it, having tried many combinations
> of
> the two INT params.
>
> g:\projects\w32ts\release> w32ts.exe
> The RPC server is unavailable.
>
>
> On Wed, 02 Jun 2010 20:50:57 -0400, vefatica <> wrote:
>
> |On Wed, 02 Jun 2010 19:25:32 -0400, Jim Cook <> wrote:
> |
> ||In fact, this happens even in safe mode. A program consisting of
> ||GetSystemTime / SetSystemTime only bleeds one handle per execution.
> |
> |Found this, which might be fun to play with. It's in W32TIME.DLL.
> |
> |typedef int ( __stdcall* W32TimeSyncNow)( const wchar_t *pwszComputer,
> |unsigned int blocking, unsigned int flags);
> |
> |Force a time sync with a network time server
> |Parameters:
> |- pwszComputer: the computer to sync the clock for,
> |NULL to sync the local computer.
> |- blocking: 0: to perform an asynchronous call (always returns 'ok')
> |1: perform a blocking call
> |- flags: probably a bitwise combination. Following combinations are
> tested:
> |0x03: just resync
> |0x06: redetect the network configuration and rediscover network
> |sources, than resync
> |
> |return value:
> |0: update successful
> |1: The computer did not resync because no time data was available
> |2: The computer did not resync because only stale time data was
> |available
> |3: The computer did not resync because the time service was shutting
> |down
> |4: The computer did not resync because the required time change was
> |too big
> |any other value: standard Windows Error
> --
> - Vince
>
>
>
>
>


--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.