Subject: Re: [boost] [interprocess] SHARING_VIOLATION due to antivirus
From: Lars Hagstrom (lars_at_[hidden])
Date: 2009-08-19 03:40:07
I made a quick patch to create_file in win32_api.hpp (the patch is
rather verbose, to make its workings obvious):
static inline void *create_file(const char *name, unsigned long access,
unsigned long creation_flags, unsigned long attributes = 0)
int tries = 0;
void * const res = CreateFileA(name, access, file_share_read |
file_share_write | file_share_delete, 0, creation_flags, attributes, 0);
if (tries > 100)
//ran out of attempts, return and let the exceptions fly
if (res != invalid_handle_value)
//all went well, return
else if (GetLastError() != 32)
//we got some other error than an ERROR_SHARING_VIOLATION,
//let the caller handle the error.
With this added my program works fine. I'm not sure whether this sort of
stuff is needed in any of the other functions in win32_api.hpp.
Lars Hagstrom wrote:
> I've discovered that there is some unfortunate interaction of
> boost::interprocess and at least one antivirus product (ESET Nod32). The
> problem manifests on some installations, and the symptom is that an
> interprocess_exception with a native error code of 32
> (ERROR_SHARING_VIOLATION) occurs when a named_semaphore (or other named
> objects) are opened (well, I've only seen it when opening, but depending
> on the AV product I guess it may happen when creating as well).
> Googling a bit on this I found http://support.microsoft.com/kb/316609,
> which suggests that AV products take exclusive locks on files just as a
> file is being opened, which sometimes upsets calls to CreateFile. What
> they suggest is doing retries when a sharing violation occurs.
> I'm not really saying that this is a boost.interprocess bug, but at
> least for me it would be handy if it was a little bit more tolerant
> towards AV products.
> I've managed (after quite a lot of hard work) to get a test environment
> where I can reproduce this quite easily, so I'm more than willing to
> help out with testing.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk