"Boost-users" <boost-users-bounces@lists.boost.org> wrote on 11/19/2014 11:51:00 AM:

> From: Aaron_Wright@selinc.com
> To: boost-users@lists.boost.org
> Date: 11/19/2014 11:51 AM
> Subject: [Boost-users] [interprocess] Bizarro File Names (Windows)
> Sent by: "Boost-users" <boost-users-bounces@lists.boost.org>
>
> I have a service that is running in Windows Server 2008 R2 SP1 that
> uses shared memory. It runs fine for a month or so, but then stops
> working correctly. When I check the C:\ProgramData
> \boost_interprocess\*\ folder, I get a bunch of weird file names, such as:
>
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EBFFFFFF
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000ECFFFFFF
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EDFFFFFF
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EEFFFFFF
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EFFFFFFF
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000F0FFFFFF
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000F1FFFFFF
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000F2FFFFFF
> 88C861CD6DE2CF014B04F3CC1200D001A40700000AFFFFFF
> 88C861CD6DE2CF014B04F3CC1200D001A40700000BFFFFFF
> 88C861CD6DE2CF014B04F3CC1200D001A40700000CFFFFFF
> 88C861CD6DE2CF014B04F3CC1200D001A40700000DFFFFFF
> ...
> (and so on)
>
> These are not even close to the names that are supposed to be used.
> They seem to increment a bit, then shift slightly, and start
> incrementing again. When I restart the service I get similar named
> files and patterns, and my services crashes because it can't grow
> shared memory (presumably because the file names are not correct). I
> have to restart the box in order to get the correct behavior.
>
> Has anyone seen this behavior before?
>
> ---------------------------------------------------------
>

Just in case anyone runs into the same problem. I finally figured out what was causing this issue.

It was caused by the issue referenced here: https://svn.boost.org/trac/boost/ticket/9767

So the bizarro file names mentioned above are caused by one process holding open file handles while another process deletes them (because the 6005 event no long exists). Apparently Windows just shows these NTFS identifiers instead of the file names because the files are actually deleted.

It seems there is just no easy way to get a reliable boot time in Windows, as the implementation of this has waffled between API calls and Event Log trolling and back again. The current code in 1.57 is not perfect yet as it can be broken by hibernation and shifts in time, as noted in the comments in the code. A work around is to specify the folder yourself at build time.