Boost logo

Boost Users :

Subject: Re: [Boost-users] [interprocess] Bizarro File Names (Windows)
From: Aaron_Wright_at_[hidden]
Date: 2015-01-28 17:55:16

"Boost-users" <boost-users-bounces_at_[hidden]> wrote on 11/19/2014
11:51:00 AM:

> From: Aaron_Wright_at_[hidden]
> To: boost-users_at_[hidden]
> Date: 11/19/2014 11:51 AM
> Subject: [Boost-users] [interprocess] Bizarro File Names (Windows)
> Sent by: "Boost-users" <boost-users-bounces_at_[hidden]>
> 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
> 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:

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

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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at