Subject: Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-01-23 01:53:10
On 31/12/2016 10:31, Ion Gaztañaga wrote:
> I've trying to find a solution with no luck. I tried:
> HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
> in modern Windows systems but hybrid shutdown (default since Windows 8)
> does not seem to update it as kernel is suspended. Searching for a
> unique bootup id in windows that does not suffer when hibernating or
> correcting the RTC is really complicated.
> Any suggestion welcomed.
Have you tried:
// error checking omitted for brevity
NetStatisticsGet(nullptr, SERVICE_WORKSTATION, 0, 0, &(LPBYTE)pstats);
// inspect pstats->StatisticsStartTime here
? It's probably still not quite foolproof, as someone could restart the
service, but it might help.
Perhaps you could check multiple sources in the hope that at least one
of them will return truth? If I understand the issue correctly, all
that's really needed is to have a session id that's unique per boot and
otherwise fixed. So the Real Problem is detecting when you need to
reset the session id.
You could do that by having a file in a well-known location (protected
by standard locking mechanisms from multiple processes initialising at
once) that contains a GUID and all the known possible boot times. If
*any* of the boot times match, then the GUID is good and can be used as
the communication directory name. If *none* of them match, then it's
probably a new boot and you generate a new GUID and write the new id and
boot sources to the file.
(For cross-version compatibility, the file will have to have keys that
describe the source of the boot time along with the value thus
calculated. Apps would ignore unknown sources and append new values if
they're happy with the session id but also know some source that wasn't
listed. Or there's a few other options.)
You could also backstop this with some native non-persistent shared
memory with a well-known name that holds this session GUID as long as
any Interprocess process is running -- on init you'd try to access this
and if it works, you know it's good; otherwise you fall back to the
file-based mechanism (and create the shared memory for the next process).
Although it would also be nice if library users could opt-in to use
shared memory with Windows semantics (it remains alive as long as at
least one process is using it, otherwise it disappears -- aka
process-persistence). This avoids the whole issue.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk