This causes that next time when application tries to open created shared memory, it has been deleted, and interprocess exception file not found has been thrown.
I don't know is this behavior a real bug, or I'm doing something wrong, but application has worked perfectly with 1.42.0 version, but due to bug #4320 I had to switch on 1.45.0.
Also, I'm interesting about reasons for shared memory folder name construction has been changed, because, I tried 1.45.0 with an old way (I edit get_bootstamp), and it worked!

I noticed the same bug. CoInitializeSecurity? returns RPC_E_TOO_LATE the second time it is called. Isn't it an error for CoInitializeSecurity? to be called more than once for a process? I'll try and revert the get_last_bootup_time to the old version.

Here is the message I sent to boost-users@… in case you need more info:

I think I have found a bug in the boost interprocess library. I would be thankful for any workaround.

I am maintaining some code that was upgraded to use boost_1_45_0 running on windows7.

Debugging this is seems to be because the boost library tries to get the windows system boot time by calling
boost::interprocess::winapi::get_last_bootup_time.. which fails for some
reason. The weird thing is that the exe (indirectly) calls this twice, and the first time it works but not the second time. (The dll also calls it twice but that works just fine.)

In get_wmi_class_attribute the time this if statement evaulates to true, next time it does not:

WMI is provoking a lot of problems for Boost Interprocess users. I've decided to remove bootstamp use in windows to obtain kernel persistence in Windows. This means that windows shared memory/queues will survive to reboots, but this behaviour is allowed by POSIX. Using bootstamps to detect reboots is doing more harm than good.