1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

time /s leaks handles

Discussion in 'Support' started by Jim Cook, Jun 2, 2010.

  1. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    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. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    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:




    --
    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. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    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:




    --
    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. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    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:




    --
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,934
    Likes Received:
    30
    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. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    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:




    --
    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.
     

Share This Page