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 Management\PrefetchParameters\BootId
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 STAT_WORKSTATION_0 *pstats; NetStatisticsGet(nullptr, SERVICE_WORKSTATION, 0, 0, &(LPBYTE)pstats); // inspect pstats->StatisticsStartTime here NetApiBufferFree(pstats); ? 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.